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. ,= ,-_-. =. [EMAIL PROTECTED] ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/
pgp7MA5t8tcQj.pgp
Description: PGP signature
