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

Re: Better support for merging local and upstream (was: Erase cache, clean registry in Linux)

On Saturday 2008 December 06 02:03, lee wrote:
> On Sat, Dec 06, 2008 at 12:45:28AM -0600, Boyd Stephen Smith Jr. wrote:
> > On Friday 2008 December 05 23:02, Stefan Monnier wrote:
> > > When an upgrade is installed, local changes *have* to be merged with
> > > the changes brought in from the upgrade.  That's just an unvoidable
> > > need.
> >
> > 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?

For example, a configuration file that was sourced as part of the startup 
script would have "[ -r /etc/package/user.conf ] && . /etc/package/user.conf" 
near the end of the file.  Another example is the configuration for gdm, the 
defaults are in /usr/share/gdm/defaults.conf, and the administrator and 
supplement or override those with /etc/gdm/gdm.conf.  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 (might be: 
error out of otherwise "break") which is under control of 
upstream/distribution and configuration files change that.

The ideal would be that files installed by packages would not be touched by 
the administrator.   It would make auditing a system easier and would also 
allow for identifying and repairing packages that were corrupted for whatever 
reason.  However, packages should also work (or some definition of work) 
immediately after they are installed, so that other packages can use them in 
their install/remove scripts.  For programs that cannot provide reasonable 
defaults themselves, they generally load settings from *a* configuration 
file, or *a* system configuration file and a user file.  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.

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.

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).
Boyd Stephen Smith Jr.                     ,= ,-_-. =. 
bss03@volumehost.net                      ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' 
http://iguanasuicide.org/                      \_/     

Attachment: pgp0kQ1TIAqIS.pgp
Description: PGP signature

Reply to: