Re: Better support for merging local and upstream (was: Erase cache, clean registry in Linux)
On Sat, Dec 06, 2008 at 03:42:42AM -0600, Boyd Stephen Smith Jr. wrote:
> On Saturday 2008 December 06 02:03, lee wrote:
> > On Sat, Dec 06, 2008 at 12:45:28AM -0600, Boyd Stephen Smith Jr. wrote:
> > > I disagree with this. It should be possible to establish "hooks" so that
> > > the administrator should not ever have to edit an installed file, but
> > > instead place additional or overriding instructions in a separate file
> > > which the packages manager would not read or modify.
> >
> > How exactly would that work?
>
> There are lots of ways to do this, but it basically boils down to
> having a distribution/upstream provided configuration and locally
> provided configuration. This is actually ALWAYS the case, as the
> source code has some default behavior
Yes, I guess you have to have something in the source to compile it. I
don't really consider that as "configuration", though.
> When the program only reads from a single file, it's difficult to
> separate distribution settings from locally administered settings,
> even though those are two different things.
It's the configuration of a program, not two different things.
When a program uses a number of different configuration files, it's
much more difficult for the administrator to configure it. I prefer to
know the configuration when I'm configuring something, and that
includes the settings made by the package manager. Having it all in
one configuration file makes it much easier, as all the settings are
in one place, and there is no guessing about what is actually
configured and no trying to find out how the configuration works. It's
plain and simple.
Fortunately, the (Debian) idea is already to have the configuration in
one place (/etc), but spreading it across multiple files (or
directories) is somewhat contradictory. As you want or need to
distinguish the administrators configuration from the package
managers, that could (better) be done by having different sections in
the configuration file or by some other way to have and keep the
package managers configuration within the file together with what the
administrator has set up.
> Thus, we have conffiles -- a half-way solution between having
> separate files for distribution and locally-administered settings.
> When/where the defaults work administrators have no worries, the
> package maintainer updates the conffiles as needed. When the
> defaults don't work, you get the dpkg prompt, which is usually
> enough; administrators that have made changes keep their old file,
> until they see an incompatable change (e.g. in the conffile format)
> and then have to rebuild their configuration. At this point they'd
> generally have to rebuild their configuration anyway.
Well, that already has been achieved to a great deal, hasn't it? Just
packages like exim4 or apache2 that use an approach which makes it
very difficult to impossible for the administrator to configure them
break it.
> Anyway, the point is that most users of F(L)OSS software don't get their
> software directly from the original authors, so it makes sense to have at
> least 3 configuration files/directories (distribution, in /usr/share mostly;
> system, in /etc mostly; and user, in ~ mostly) for any user application, and
> 2 (the first 2) for non-user applications. [It would also be nice to
> have "site" configuration in /usr/local/share or somesuch.] Unfortunately,
> this doesn't happen often and we get half-way solutions like conffiles (or
> Gentoo's equivalent).
Hm, when I switched from Suse to Debian, one of the advantages of
Debian was that they stayed closer to what the original authors
did. That made it a lot easier to, for example, get a newer version of
a software and use that instead of what came in the distribution ---
not only with configuring it, but also with compiling it and keeping
that version installed.
Too much automatic doing is a bad thing; it doesn't work for other
OSs, and it doesn't work for Debian (see exim4 and apache2).
--
"Don't let them, daddy. Don't let the stars run down."
http://adin.dyndns.org/adin/TheLastQ.htm
Reply to: