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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx

Relevant Pages

  • Re: Better support for merging local and upstream (was: Erase cache, clean registry in Linux)
    ... having a distribution/upstream provided configuration and locally ... much more difficult for the administrator to configure it. ... installation and multiple apache2 installations and I greatly prefer ... package managers configuration within the file together with what the ...
    (Debian-User)
  • SP2 and Acrobat Add-on
    ... Checking the Manage Add-ons screen in the Control Panel/Internet ... settings are greyed out. ... Running GPEDIT.MSC shows that Computer Configuration | Administrative ... The strange thing is that as administrator, everything works fine, and the ...
    (microsoft.public.windowsxp.help_and_support)
  • Re: Cannot Modify IP Settings
    ... If this is a domain computer logon as the local administrator - not a domain ... causing the problem from user configuration but usually the user would just ... > modify any settings on the Advanced TCP/IP Settings dialog of the active ... > disabling NetBIOS over TCP on the WINS tab, ...
    (microsoft.public.windows.server.security)
  • Re: no privileges for accessing connection properties
    ... User Configuration, Administrative Templates, Network, Network Connections. ... Enable Windows 2000 Network Connections settings for Administrators. ... Contact your administrator" when I right ...
    (microsoft.public.windowsxp.security_admin)
  • Re: Win 2008 registry problem
    ... MS-MVP (Windows Client), Aumha.net VSOP, DTS-L ... Administrator account. ... Administrator', then it starts and runs ok but of course it has the ... Administrator's configuration, not necessarily what I want for the second ...
    (microsoft.public.windowsupdate)