Re: Better support for merging local and upstream (was: Erase cache, clean registry in Linux)
- From: "Boyd Stephen Smith Jr." <bss03@xxxxxxxxxxxxxx>
- Date: Sun, 7 Dec 2008 17:10:06 -0600
On Sunday 07 December 2008, lee <lee@xxxxxxxxxxxxxxx> wrote about '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:wrote:
On Saturday 2008 December 06 02:03, lee wrote:
On Sat, Dec 06, 2008 at 12:45:28AM -0600, Boyd Stephen Smith Jr.
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.
But it is. It's the underlying "defaults" that 1) your configuration
alters and 2) could change the same way a distribution-provided
configuration might.
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.
It is. They are maintained by two separate entities. Just like the
default behavior is maintained by the original author and the
configuration is maintained by others.
When a program uses a number of different configuration files, it's
much more difficult for the administrator to configure it.
I completely disagree here. Your specific examples, apache2 and exim4
simply convince me further that you are wrong. I maintain a exim4
installation and multiple apache2 installations and I greatly prefer
separated files to a single file.
It's easier to work with that way, not harder.
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.
No, separate files is better, since files are already a natural unit. 'rm
my.conf' (and leaving debian.conf) is easier than editing a single file to
remove local changes.
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?
Well, it's achieved less than the alternative would, but with arguably less
work.
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.
I find the debian way of configuration apache2 superior to other
distributions I've used. I've never installed exim4 on a different
distributions, but I do think it would be troublesome making changes to a
single, large file then the logically separated small files in well-named
directories used by Debian.
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.
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.
I guess. There are certainly changes in Ubuntu/openSuse that I don't see
in Debian packages, but Debian (particularly the security team) is very
adamant that Debian must be able to make changes without prior approval
from the original authors to better serve the needs of it's users. (E.g.
firefox vs. iceweasel)
Also, some upstream programs may not need their source changed, but still
need to be "configured" to work immediately after the package as been
installed on a Debian system. This might mean looking somewhere other
than upstream expected for libraries, reading configurations
from /etc/<package>/<package>.conf instead of /etc/<package>.conf, or
simply having some defaults provided so the program doesn't "give up"
until the user manually fiddles with it.
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.
Down that road lies danger, unless you properly segregate "packages" not
under control of the package manager OR properly inform the package
manager of their existence.
Too much automatic doing is a bad thing;
Then throw away your computer and get out your pen and paper. The only
things computers do is automate tasks, all of it can be done manually.
The more things that are automated, the less labor is required, and the
more time can be spent focusing on less menial tasks.
Caveat: Automating something that is not menial is generally a dangerous
path. Since it is not menial, it needs some sort of conscious, generally
considered and informed, input which computers (and other non-sentient
machines) cannot provide.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss03@xxxxxxxxxxxxxx ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.org/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.
- Follow-Ups:
- References:
- Prev by Date: remote system administration - grub via serial cable?
- Next by Date: Re: Kernel 2.6.27 in Debian?
- Previous by thread: Re: Better support for merging local and upstream (was: Erase cache, clean registry in Linux)
- Next by thread: Re: Better support for merging local and upstream (was: Erase cache, clean registry in Linux)
- Index(es):
Relevant Pages
|
