[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

A nebulous system registry ...



Greetings from down unda ...

    I am aware that this message sort of veers away from the current
thread of discussion
but Ive got an itch I have to share ....

    One of the things I noted earlier in this list is the lack of a
standard registry . It was pointed
out that the job of the lsb was not to define an implementation of a
registry . It has occurred
me that the interactions between packages , the various package
managers  and autoconf is
non existant . Fair enough . I want to seggest maybe , that rather than
defining the implementation
of a registry , how about just defining a location ( or even a format
and a location if that doesnt go
too far ) for the storage of local system information . I realise that
this would probably be a real
hairy concept on a thin client host that has applications served to it ,
but its obvious that there is
a need to standardize the base of information that various packagers and
configuration utilities
need in order to complete their jobs in a reasonable manner .

    This could have the following advantages :-

    1) It could relieve the burden that autoconf has to go through with
running its various checking
algorithms to ascertain the current state of an machine . Although  the
configure scripts produced
by autoconf are fairly reliable , there is still room for it to really
stuff up .

    2) It could allow the various packaging methods to have a standard
place of information storage
so that they can all interact together and maintain a (hopefully
reasonable )consistent representation
of a machines' current installed base .

    3) It could provide the humble administrator or user with a starting
place to ascertain the state
of a machine without having to wade through reams of lib files and
binaries . ( not to mention
shared libs , macros , config files .. etc ...etc )

    4) It could hopefully reduce the ammount of divergence between
system information definitions
both now and in the future .

    The disadvantages would be that something like this is not
standardized yet and that there would
be some pain in the  transition since there seems to be no co-ordination
between the various
packaging / configuration utilities at this time . This pain would be
inversely proportional to the
thought put behind defining the place . However if no standard is
defined (ever ?) then new packaging
methods will probably continue to  diverge resulting in greater
fragmentation of the package /
configuration methods and making the task of standarizing this area even
more difficult  .

    I suppose what I am saying is if you define a place , they will use
it ...

    Ooops are my shoes wet or am I just pissing in the wind ???

Cheers Mik Voase .

( goes back to lurking quietly in the backround )



Reply to: