On Sunday 07 December 2008, lee <lee@yun.yagibdah.de> 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: >> 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. 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@volumehost.net ((_/)o o(\_)) ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-' http://iguanasuicide.org/ \_/
Attachment:
signature.asc
Description: This is a digitally signed message part.