Re: Better support for merging local and upstream (was: Erase cache, clean registry in Linux)
On Sun, Dec 07, 2008 at 05:10:06PM -0600, Boyd Stephen Smith Jr. wrote:
> 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.
You have a program that does (or does not) something. Then you can (or
can not) configure it to do something else. Or you can change the
program.
> >> 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.
It's the same thing, i. e. configuring a program. There may be
different configurations and different ways to configure it.
> >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.
Well, it's not.
> >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.
That might be easier or not, but configuring a program involves not
only removing something. It involves knowing the configuration,
knowing what options are available and knowing how to change them. The
automatic configuration of apache2 and exim4 makes this extremely
difficult. It turns "knowing the configuration" into a puzzle with no
way of putting it together to see the whole picture. It turns "knowing
what options are available" into a puzzle of juggling with many
different pieces, also without a way to put them together to see the
whole picture, and it adds another level of difficulty by eventually
forcing you to find more pieces in various documentation --- pieces
that otherwise would be readily available within the configuration
file as comments. It turns "knowing how to change" options into having
to to try to figure out how to use the automatic configuration --- and
that alone is extremely annoying because you can't just configure one
thing (the program you're about to configure) and focus on that, but
instead you have to "configure" an automatic configuration at the same
time while you don't want to have to deal with that.
There is nothing easier or better about that, not for the one who
tries to configure a program. It only makes it much more difficult. It
might make it easier for programs to configure programs, but for every
case in which you need to do it yourself anyway, adding complexity and
difficulty doesn't make it easier.
> >> 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.
You mean it _is_ achieved or _has_ achieved?
> >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.
There's nothing troublesome about editing a configuration file like
exim uses. Just load it into your favourite editor. What could be
easier?
But how does the automatic configuration work? There are some
directories, very confusing, there are some files in them, even more
confusing. There is exim4.conf.template, not human readable/editable,
and, impossible to figure out, update-exim4.conf.conf (What kind of
retarded file name is that??). That's nothing but troublesome. Then
try to change something, and you'll find it doesn't work, and it's not
possible to find out why because the documentation isn't helpful.
I just wanted to configure exim, not mess around for hours with all
these files and directories, with trying to find documentation about
the automatic configuration, with trying it out in an attempt to make
it do what I wanted, still with no change of knowing how it's
configured even if it worked ...
So just copy the example, modify it, and it's done. Very easy, never
bother with the automatic crap again.
Apache2? If I really wanted to configure it, I'd try to find a sample
configuration, modify it and use that. There's no point in try to mess
with all these files.
> 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.
There are some things I would rather have not work/start automatically
before I check their configuration.
> >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.
What would the danger be? When installing my own software, I'm not
using packages --- I've no idea how to make one anyway. If I'd use
packages, yes, that could interfere with other packages.
In that particular case, I wanted to use qmail because I couldn't get
sendmail to do what I wanted. There was no package for qmail, so I
compiled it myself --- fortunately, that worked, unlike other software
that sometimes wouldn't work because Suse had changed
something. Sendmail was (is?) default on Suse, so the package manager
kept nagging me about installing it, and every time I installed or
removed a package, sendmail would be selected for installation
automatically, and I had to deselect it. Installing it would break my
qmail installation. When I wanted to upgrade to 7.0, the package
manager managed to overwrite my qmail installation again, this time
without any asking or telling me, and I was fed up with Suse and
changed to Debian.
Now Debian is coming up with similar things like the automatic
configuration for exim4 and apache2. That just sucks.
> >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.
That isn't true.
> 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.
I'm not sure what menial means, but it seems to me that I won't
consider administering a mail server or a web server a menial task.
--
"Don't let them, daddy. Don't let the stars run down."
http://adin.dyndns.org/adin/TheLastQ.htm
Reply to: