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

Re: Goals for 1.3?



On Mon, 23 Dec 1996, Bruce Perens wrote:

> From: Winfried Truemper <winni@xpilot.org>
> On Sat, 21 Dec 1996, Marek Michalkiewicz wrote:
> > > Hmm, I feel a little nervous about putting thigs like
> > > 
> > > SULOGIN=`cfgtool --get boot.sulogin`
> > > 
> > > at the very beginning of /etc/init.d/boot.  Why not just:
> > >
> > > . /etc/default/boot
> > 
> > Yes, you're right. :-)

Isn't a better (=faster) way of doing it:-

eval `cfgtool --get boot.\*`

> 
> No, I disagree. We're trying to take a step forward, not back. Sourcing
> lots of shell files means you need to have a tool to generate little shell
> files and a whole tree of little shell files wasting space, and no
> centralized management of configuration data, and no hierarchical
> organization of configuration data. It would be much better to have all
> of this information in one database.

Agreed.

> 
> > I've experimented with "cfgdb" this weekend and it's much too slow for too
> > little gain.
> 
> You experimented with the SHELL version of cfgdb. No wonder it was much
> too slow! Once you are satisfied with the program it should be rewritten
> in C.
> 
> > I mean, we deal with static information and there is no good
> > reason to convert the settings for the shell to read on the fly.
> 
> There is a very good reason. We want to be able to administer systems
> remotely, and we want to be able to set up a new system easily given a
> list of settings. The database lends itself to that.
> 
> > Yes, but the rest what I wrote was nonsense. Too many ideas mixed up.
> > The easiest way to implement defaults (in the sense of "apllication
> > defaults") is to source in twice:
> 
>         . /etc/defaults/boot
>         . /etc/script-env/boot
> 
> PLEASE do not implement it this way. Do not make it necessary to have
> hundreds of little files to run a Debian system. Do it in one database,
> with a program to hide the format of the database from the rest of the
> system.

The way it should probably run should be to have two databases - the
defaults, which is updated by preinst/postrm scripts, and the other user
values, which are entered by the user, and deleted by postrm purge
(possibly).

-- 
Tom Lees <tom@lpsg.demon.co.uk>			http://www.lpsg.demon.co.uk/
PGP ID 87D4D065, fingerprint 2A 66 86 9D 02 4D A6 1E  B8 A2 17 9D 4F 9B 89 D6
finger tom@master.debian.org for full public key (also available on keyservers)


--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-REQUEST@lists.debian.org . Trouble? e-mail to Bruce@Pixar.com


Reply to: