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 )
