Re: RFC: A method to use Admin tools, like linuxconf
On 20 Feb 1997, Manoj Srivastava wrote:
> Hi,
> [this is getting to be fun]
> >>"Shaya" == Shaya Potter <spotter@itd.nrl.navy.mil> writes:
>
> Shaya> Let me start off fresh with the plain idea no fancy language.
>
> Shaya> right now a packafe includes the init scripts and puts them in
> Shaya> /etc/init.d/ it then tells SysV init when to launch them by
> Shaya> running update-rc.d. This installs links into the rc*.d tree.
> Shaya> This is limiting in the fact, that if someone wants to use
> Shaya> linuxconf, it is almost totally incompatable with debian.
>
> Right. Of course, I'd say (putting the emphasis the other
> way), Linuxconf is totally incompatible with debian, and that limits
> Linuxconf (can we get it to change? ;-)
see my previous message about meeting half way.
>
> Shaya> What I tried to propose is, 1. we give a little abstraction
> Shaya> layer to update-rc.d, what I called "configure". This
> Shaya> abstraction layer is the database file. The database file
> Shaya> should never be consulted after dpkg configures the package,
> Shaya> unless perhaps we want to reconfigure the system. What my
> Shaya> modified version of update-rc.d, or the "configure" program
> Shaya> each package installs, does is to parse the database file and
> Shaya> creates what files that package needs, such as linuxconf's
> Shaya> dropins.
>
> Do not store the same information in two lpaces, unless you
> are willing to invest a great deal of effort in synchronization and
> coherency tools. Second, all the data that you want to put into the
> database already exists on the file system. Is there a technocal
> reason to require a formal database, with the added opacity, to this
> situation? Do we need formal database advantages?
The database file, will be in /var/lib/dpkg/info, under
package_name.database. This file will be removed when a package is
removed. The only reason it will be kept around is for use in
reconfiguring packages. The database will not be used for anything
except configurations. AGH haven't I said this already. The file system
will be constructed from the databse file I am proposing. The database
shouldn't be any more opaque b/c it should never be seen.
>
> Shaya> I don't want to get rid of init. I believe we can live with
> Shaya> SysV init. We might not even include Linuxconf in the main
> Shaya> distribution at first, put it into contrib, but at least put
> Shaya> more hooks into the release so that it is easier to use it.
>
> I vote we put more hooks into Linuxconf to make it easier to
> use on Debian systems ;-) ;-) ;-) (I *am* trying to make a point
> here).
I agree, bu twe can do out best to meet them half way.
>
> Shaya> Now that I have digressed a little, let me get back to what I
> Shaya> was saying, what I am proposing does not involve putting
> Shaya> anything in any proprietary database that is looked up at boot
> Shaya> time, configuration is done at package configuration time, just
> Shaya> like we run update-rc.d. Instead of update-rc.d putting
> Shaya> symlinks into the rc*.d tree, it does whatever is neccesary for
> Shaya> the init manager. Is this clear. I am not proposing a
> Shaya> structure for this database file, that is a topic for another
> Shaya> discussion, hopefully once we get over this hump.
>
> My question is, why? Is there a technical requirement for
> this? Remember, we have to invest time and effort, which may be
> spent better elsewhere. This new method will also have to be tested,
> and the glitches worked out. I need to be convinced of the
> superiority of your methos before I vouchsafe it.
So we can put it in experimental or contrib for a little bit b/4 we allow
it into the standard distribution, we may even design a stress test for
it, see what it can handle and what we can do to make it break.
>
> Also, I think that symlinks in directories are simpler. Never
> under estimate the value of the KISS principle.
I agree, but then there is the ADA approach, hey its hard to start a
project, but look what happens when the military has to upgrade weapons
in the field, much easier. This isn't about ADA though, don;t bring in
ADA, my father was one of the people that helped design it so I don;t
want to hear anything about it :-).
>
> Shaya> To answer the question of Linuxconf storing configuration data
> Shaya> in proprietary places, IT DOESNT. It uses the standard tools,
> Shaya> so it must store their configuration files in their standard
> Shaya> places. Some of the other data, which doesn't have a standard
> Shaya> place to put the configuration data, like ethernet stuff, it
> Shaya> puts in its own configuration file (at least from my
> Shaya> understanding of linuxconf's docs.) It actually detected many
> Shaya> of my setting automatically on a test Debian system I installed
> Shaya> it on, by reading the standard files, and it would write
> Shaya> changes to those files.
>
> And it reads data from the standard locations as well? (so my
> changes are not lost). If this is so, why are we having this
> discussion? Seems to me that Linuxconf can be put into place
> transparently, and requires no action from the general developer
> community.
>
> Oh, sorry. It puts *Standard* data in the usual place, but
> everything else goines in a non-standard place determined by
> Linuxconf. Hmm. Hmm. Could you tell us what the file is, please? (I
> don't have access to LinuxConf). And what format the data is kept in?
I havent been able to play around with Linuxconf as much as I want to,
but I would think it something like linuconf.conf, I'll have to check, I
think it is also a text file. Its hard to play around with it b/c I
don;t use Slackware anymore, only Debian :-), and since we don't support
it, I don't want to delve into it to much.
>
>
> Shaya> Now if you don't like the fact that linuxconf puts all the non
> Shaya> standard data in one file, we can probably work with its
> Shaya> developers to split that data up, and maybe put it into files
> Shaya> which make more sense, (Hey we may even be able to publish a
> Shaya> standard which other Distributions can follow). More examples
> Shaya> of this data which doesn't have a standard place, is the Linux
> Shaya> firewall rules. Usually you would just call ipfwadm by hand,
> Shaya> linuxconf will set the rules for you. Since their is no
> Shaya> standard place of putting this data, linuxconf stores it in its
> Shaya> own file, which as I said b/4 I think is plain text.
>
> I wholeheartedly agree! Yes!
Good.
>
> Shaya> Well, please respond.
>
> You got it.
Well how do you like my response. ;-)
Shaya
--
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: