FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 12-06-2008, 07:03 AM
lee
 
Default Better support for merging local and upstream (was: Erase cache, clean registry in Linux)

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? Think of /etc/exim4/exim4.conf, for
example --- I'm already bypassing the automatic configuration because
I was unable to figure out how to make it do what I want and because I
don't want to use it because it's not human readable and editable and
I wouldn't know how exactly exim is configured. To use the automatic
configuration, you do not only need to know how to configure exim, you
also would have to know how to use the automatic configuration to get
it to create the configuration you want. That makes it at least twice
as difficult to configure exim.

Now, given that you use the automatic configuration, you want to add
another level of difficulty by having another configuration to
counteract the automatic configuration. Configuring exim would become
at least three times as difficult as needed because you would have to
learn how to configure exim, how to make the automatic configuration
do what you want and then how to counteract the automatic
configuration.


Using /etc/exim4/exim4.conf is already providing "additional or
overriding instructions" the package management doesn't touch. I
wouldn't want package management software to interact in any way with
my instructions, so merging something or having to provide only
particular instructions against what the package management does is
out of the question: It's easy to overlook something that the package
management does which would require me to counteract it, especially
when installing updates that might unexpectedly activate new
features.

With that kind of complexity, people will start asking if they can't
go back to configure things themselves --- like they already do with
exim. If I was serious about apache2, I would do the same for apache2,
completely bypass the automatic stuff. Frankly, I don't know how the
apache2 I'm running is configured because the automatic stuff hides
the configuration from me. It's working, it doesn't matter much, but
if it was an important service, I'd have to bypass the automatic
system because I would need to know exactly what's configured.

And it's the same as with exim: You'd have to know how to configure
apache2, then you'd have to know how to make the automatic
configuration create the configuration you want, and then you'd have
to know which "additional or overriding instructions" you need to
give. That's at least three times as difficult as just configuring
apache2 yourself.

The package management software just needs to tell you that it wants
to make changes, what these changes would be and to give you the
option to decide what you want. That's what it does now. If an update
brings changes, I want to know what these changes are. I don't want
them to be hidden from me by automatically changing or merging
configurations.


--
"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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-07-2008, 08:50 PM
lee
 
Default 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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-09-2008, 06:33 PM
lee
 
Default Better support for merging local and upstream (was: Erase cache, clean registry in Linux)

On Sun, Dec 07, 2008 at 08:24:45PM -0200, Eduardo M KALINOWSKI wrote:
> From: lee <lee@yun.yagibdah.de>
> > When a program uses a number of different configuration files, it's
> > much more difficult for the administrator to configure it.
>
> I'd say it's a matter of preference. I like exim's split configuration, it
> makes upgrades easier as I only have to deal with the parts that I've
> changed. And perhaps not even that, if I can make a change by adding a new
> snippet file instead of changing an existing one.

Well, I don't like it, it would make configuring exim impossible if I
couldn't bypass it. Using a single configuration file, you as well
only need to deal with the parts that need to be changed. But you
would know what is configured and what needs to be changed which is
impossible with the automatic configuration.

> For those who prefer a single file, debconf allows that, satisfying all
> kinds of people. You can even dump debconf altogether and do all the
> configuration yourself.

Yes, it's good to have a choice. The problem is that the choice
eventually gets taken away.

> > 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.
>
> That's your opinion. Do not take it as absolute.

It's a matter of fact. You can try it by, for example, installing php
for apache2. You're not being told what needs to be done with the
apache2 config, it gets modified automatically. Then you find that it
doesn't work, not before restarting apache2 manually.

Exim4 is another example. I can configure it easily bypassing the
automatic configuration, but I'm unable to configure it using the
auomatic configuration. What about changes if you use the automatic
configuration? Would you be told what is being changed? Or would your
mailserver suddenly be configured differently without you even knowing
about it?

> I don't know about apache, but as I said, with exim it's quite easy
> to use a single file, if you prefer it that way.

Well, where is the option to have the automatic configuration create a
single configuration file that you can easily check and then use to
configure your program if you want to?


--
"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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-09-2008, 07:00 PM
Eduardo M KALINOWSKI
 
Default Better support for merging local and upstream (was: Erase cache, clean registry in Linux)

lee wrote:
> Exim4 is another example. I can configure it easily bypassing the
> automatic configuration, but I'm unable to configure it using the
> auomatic configuration.

Well, you can't, but other people can (at least one, ie, me). It's a
matter of preference, and Debian respects that.

> Well, where is the option to have the automatic configuration create a
> single configuration file that you can easily check and then use to
> configure your program if you want to

It's explained in the README.Debian file, which contains all the details
about how exim works in Debian and the peculiarities relevant to this
distribution.



--
Eisenhower!! Your mimeograph machine upsets my stomach!!

Eduardo M KALINOWSKI
eduardo@kalinowski.com.br
http://move.to/hpkb


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-09-2008, 07:47 PM
lee
 
Default 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


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 12-09-2008, 07:58 PM
lee
 
Default Better support for merging local and upstream (was: Erase cache, clean registry in Linux)

On Tue, Dec 09, 2008 at 06:00:34PM -0200, Eduardo M KALINOWSKI wrote:
> lee wrote:
> > Exim4 is another example. I can configure it easily bypassing the
> > automatic configuration, but I'm unable to configure it using the
> > auomatic configuration.
>
> Well, you can't, but other people can (at least one, ie, me). It's a
> matter of preference, and Debian respects that.

It doesn't ask you what you prefer.

> > Well, where is the option to have the automatic configuration create a
> > single configuration file that you can easily check and then use to
> > configure your program if you want to
>
> It's explained in the README.Debian file, which contains all the details
> about how exim works in Debian and the peculiarities relevant to this
> distribution.

Where does it explain how to use the automatic configuration to create
a single configuration file? Where does it explain how to use the
automatic configuration to create a single configuration file that has
the exact same options I'm using now?

And it's another readme I won't have to read if they hadn't changed
the way exim is configured from exim3 to exim4.


--
"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@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 

Thread Tools




All times are GMT. The time now is 07:40 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org