Registries and such ..

[Michael H. Voase]

    Greetings again from down unda ...

    The segestion of the perl based Windows style registry was
interesting but I think you
have missed my point a little . The idea that Im trying to get across
isnt  related to the
individual configurations of each package . That is , the  individual
configurations for each
package are in well defined places ( ie /etc , /usr/etc and  such as
perscribed by fsstd 2.0 ) .
I agree that there are  many useable configuration tools  available (
such as Registry.pl
and Linuxconf ) to assist the user / sysadmin in configuring the
individual  programs with
the results usually residing in .conf and rc files . No point in
defining what is already defined .

    To this end I  have attatched a bad description by using the word
'registry' . The
concept of a registry in Windows more refers to the configured state of
the individual
programs installed on a given PC . For a correspondence of what I am
trying to get at ,
think of the add/remove programs section of the Windows configuration
panel , as
a somewhat simple example .

    However what does not seem to be defined is a general consensus on
where and in what
format to place the information on what is actually installed on a given
machine , what those
packages depend on and what state the build environment of the machine
is in . Since the two
main methods of package distribution comes down to pre-compiled packages
of various flavours
and   the humble source  tree  , what I am segesting is that  an
agreement should be reached as to
where such overall  system  information could be stored . Possibly in
the hope that maybe , for
example , when a configure script goes to generate a makefile for
building a program , it could
refer to a given place where information such as what Libs are present ,
what compilers / makers
are present , is the make program broken ,  is the compiler POSIX
compiant and so on is stored .
When the makefile actually installs the program , it could  then add its
own record to the
'state archive' to simply indicate that it is  present and that it
depends on libs / programs x,y, and z
for  its correct function  .   Extending  the concept , the  makefile
could even leave an uninstall
script lying  around that removes said package along with its 'state
archive' entry to indicate
that it is no  longer present on the  machine .

    If the pre-compiled package formats can agree on a single place to
put such info , then
they can utilize this information and update it as  necesary as well .

Of course when a package is installed that affects the build environment
of a given machine
(such as a new compiler or make program ) it would need to run a
conformance script  ( such
as the configure scripts created by autoconf ) to establish the nature
of the compiler / make
program and then store the results . It is something that is done
already when a program is built
from source . The difference is that instead of running the conformance
sections for every
program built on a machine , it only needs to be run once when a new
compiler or maker is
installed on a machine .

Something like this would  have to be the result of all parties involved
agreeing on a standard
place to put such info so that all packaging  methods can call on such
info and update as
needed . The end result would be that no matter wether one installs a
package from a deb file ,
an rpm file  a tar.gz file or from source , the results of that
installation can be recorded used
for future reference . Especially noting that software writers  would
like this since a
consistent  archive can be called upon to assess the state of a machine
that is about to
have software installed upon it and that adequate steps can be taken to
ensure smooth
installation and successfull operation .

    From this point , then a linuxconf style program or Registry program
can go to work to
actually configure the individual package to suit its new
responsibilities .

    Clear as mud now ??

Cheers Mik Voase .

( Last time , Im running away and hiding under my rock now ... bye )