"The Debian exim 4 packages suck badly" on exim-users@exim.org
Marc Haber
mailing lists? Can't we have internal flamage internally?
Ian Jackson <ijac...@chiark.greenend.org.uk> wrote on
exim-...@exim.org:
>To: Marc Haber <mh+exi...@zugschlus.de>
>From: Ian Jackson <ijac...@chiark.greenend.org.uk>
>Sender: exim-user...@exim.org
>Cc: exim-...@exim.org
>
>Marc Haber writes ("Re: Bug#276126: [exim] allow headers_remove|add options to be given multiple times"):
>> I am pretty well aware that Debian is unpopular with exim upstream
>> [...]
>
>Debian is rightly unpopular with Exim upstream because the Debian
>Exim4 packages have a vastly overcomplicated and buggy configuration
>generator which causes hassle upstream, and because the Debian Exim
>maintainers have badly managed the communications with upstream.
Other readers, please take a look at #295391 before participating in
the flamewar.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Greg Folkert
[...let's all get along outside Debian please snippage...]
> Ian Jackson <ijac...@chiark.greenend.org.uk> wrote on
> exim-...@exim.org:
> >To: Marc Haber <mh+exi...@zugschlus.de>
> >From: Ian Jackson <ijac...@chiark.greenend.org.uk>
> >Sender: exim-user...@exim.org
> >Cc: exim-...@exim.org
> >
> >Marc Haber writes ("Re: Bug#276126: [exim] allow headers_remove|add options to be given multiple times"):
> >> I am pretty well aware that Debian is unpopular with exim upstream
> >> [...]
> >
> >Debian is rightly unpopular with Exim upstream because the Debian
> >Exim4 packages have a vastly overcomplicated and buggy configuration
> >generator which causes hassle upstream, and because the Debian Exim
> >maintainers have badly managed the communications with upstream.
Debian is unpopular Many places where Debian has changed the "globbed"
config. Many people HATE little bitty files to make things work. Me,
best thing since Sliced Bread. Except I'd rather see --keepcomments as
default and changed to --removecomments. My only gripe, pretty minimal.
> Other readers, please take a look at #295391 before participating in
> the flamewar.
I for one would LOVE to see Ian produce an exim4 configurator... why not
make one for Webmin. The current thing in Webmin only does monitoring.
That way, it COULD be use standalone (with a wrapper) or with Webmin.
Or Ian, could just look at this configuration setup as a way to keep
Hosting Providers happy as dropping a file into routers, basically can
setup a whole virtual domain. I use it that way. Best part is when they
leave, remove the router and they are gone. I also have split up configs
for other mail apps and Webservers, domain specific [PHP|Perl|
Pyhton]/[pgsql|mysql] settings for Apache too. Drop the file in the
right spot... voila all done.
If you cannot see how making it bigtime massive sitehosting friendly...
is a bad thing at all. You *DO* have an option to just use the Bigfile
anytime... make sure the the file /etc/exim4/exim.conf is there and not
a symlink.
--
greg, gr...@gregfolkert.net
The technology that is
Stronger, better, faster: Linux
Blunt Jackson
>
> Debian is unpopular Many places where Debian has changed the "globbed"
> config. Many people HATE little bitty files to make things work. Me,
> best thing since Sliced Bread. Except I'd rather see --keepcomments as
> default and changed to --removecomments. My only gripe, pretty minimal.
>
As a general note, I find it annoying, frustrating, and confusing
whenever ANY debian
package has a substantially different installation or configuratin
mechanism than the
mechanism documented by the software publisher.
Taking Exim as an *example* of this, when I installed Exim, and ran into some
problems configuring it the way I wanted, comparing the application
documentation
on the Exim website with what apt-get installed I found it utterly
different. The Exim
website gracefully acknowledged the Debian configuration mechanism as "elegant"
and then advised that if I needed help with it, I should contact the
debian distribution
owners. Maybe I missed some great documentation out there, but using Google, I
found no such documentation.
Exim is by no means the only package to do non-standard things, it seems like a
debian package maintainer's sole objective in life is to take a
perfectly reasonable
./configure
./make
./make install
and do utterly wacked out things to it. The upside *may* be having a
debian system
that does things the "debian" way, which way is more "elegant" (or
more secure, a
perfectly laudable goal) -- but the downside is clearly that the
installation, and often
configuration support from the original software team is largely useless.
I am perfectly open to understanding why my frustrations with debian
packages are
(A) due to some ignorance of debian documentation, or (B) inherently
unreasonable.
Currently, I feel they are (C) the cost of working with an otherwise excellent,
reliable, and philosophically congenial distribution.
Packages I expect to work closely with (ie., more than just
run-it-out-of-the-box) I
usually bypass the debian package system and get the manufacturer's
distribution.
Sincerely,
-bluejack
-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
--
To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Marc Haber
>default and changed to --removecomments. My only gripe, pretty minimal.
And fixed soon. #295735.
William Ballard
> and do utterly wacked out things to it. The upside *may* be having a
The exim4 config asks you if you want itty bitty or one monolothic
config file. It offers you the option of doing it the upstream way.
What's the problem?
Florian Weimer
> Taking Exim as an *example* of this, when I installed Exim, and ran
> into some problems configuring it the way I wanted, comparing the
> application documentation on the Exim website with what apt-get
> installed I found it utterly different.
Just because the configuration file is called /etc/exim4/exim4.conf
instead of /usr/exim/configure? Oh dear.
John Hasler
> The exim4 config asks you if you want itty bitty or one monolothic config
> file. It offers you the option of doing it the upstream way.
Does it tell you which is the upstream way? Most new users won't know.
--
John Hasler
Henning Makholm
> As a general note, I find it annoying, frustrating, and confusing
> whenever ANY debian package has a substantially different
> installation or configuratin mechanism than the mechanism documented
> by the software publisher.
Perhaps Debian is not the distribution for you, then. We have always
prioritized constistency across the entire Debian OS over adherence to
what upstream authors somehow chose to do.
I maintain one package whose upstream author apparently thought that
$PATH would be a good place to look for a system-wide configuration
file. I changed that to look in /etc instead, which makes the
configuration mechanism in Debian substantially different from
upstream's. You may find this annoying, frustrating and confusing, but
it's how Debian operates.
--
Henning Makholm "De kan rejse hid og did i verden nok så flot
Og er helt fortrolig med alverdens militær"
John Hasler
> I maintain one package whose upstream author apparently thought that
> $PATH would be a good place to look for a system-wide configuration
> file. I changed that to look in /etc instead, which makes the
> configuration mechanism in Debian substantially different from
> upstream's.
I have made similar changes, but I also patched the documentation. Many
DDs do not do so, confusing users.
--
John Hasler
Kevin B. McCarty
> Henning Makholm writes:
>> I maintain one package whose upstream author apparently thought that
>> $PATH would be a good place to look for a system-wide configuration
>> file. I changed that to look in /etc instead, which makes the
>> configuration mechanism in Debian substantially different from
>> upstream's.
>
> I have made similar changes, but I also patched the documentation. Many
> DDs do not do so, confusing users.
Please consider filing bugs against the packages you know of where the
documentation hasn't been patched to match the config changes.
--
Kevin B. McCarty <kmcc...@princeton.edu> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG public key ID: 4F83C751 Princeton, NJ 08544
Blunt Jackson
> Scripsit Blunt Jackson <bluu...@gmail.com>
>
> > As a general note, I find it annoying, frustrating, and confusing
> > whenever ANY debian package has a substantially different
> > installation or configuratin mechanism than the mechanism documented
> > by the software publisher.
>
> Perhaps Debian is not the distribution for you, then. We have always
> prioritized constistency across the entire Debian OS over adherence to
> what upstream authors somehow chose to do.
Obviously there's a balance. I wasn't looking for flames. I believe I
did explain *why* debian was my distribution of choice even so.
> I maintain one package whose upstream author apparently thought that
> $PATH would be a good place to look for a system-wide configuration
> file. I changed that to look in /etc instead, which makes the
> configuration mechanism in Debian substantially different from
> upstream's. You may find this annoying, frustrating and confusing, but
> it's how Debian operates.
And clearly, *this* is a scenario in which the upstream author was way
outside the *unix* standard way of doing things. I'm not saying
there's any clear-cut answer, other than to hope that both upstream
developers and debian package maintainers use common sense.
One distinction is in applications that the majority of users just
want to work out of the box, and forget about. If I had to tweak the
configuration of every application on my servers, I would be a
frothing maniac. But there are some biggies, some very well known
applications, that, when installed for any practical purpose,
generally require somewhat sophisticated user oversight. Exim is one,
Apache is another. Mysql is a third. I put in the time to figure out
the debian way of doing Exim (and I'm still not sure I understand it,
but at for now I have it working). There was a substantial amount of
hair pulling and cursing due to the disparity between what I saw on my
hard drive and what I saw in the online documentation. After that
experience, when I installed apache and mysql, and saw they were doing
their own thing as well, I decided I didn't want to learn go through
the same frustration with applications I already knew pretty well. I
removed the debian packages, and compiled my own from the upstream
developers. Note that removing the debian packages did not remove all
their config files and so forth, there was a fair bit of manual
cleanup afterwards -- but I'm not using the stable distribution, so I
don't expect perfection.
As for you, Florian's snide comment:
> Just because the configuration file is called /etc/exim4/exim4.conf
> instead of /usr/exim/configure? Oh dear.
No, it was the stuff like this that made me pull out my hair:
domainlist local_domains = DEBCONFlocal_domainsDEBCONF
How do I figure out where that DEBCONF stuff is coming from? What it means?
Of course, it didn't help that during the install I didn't quite know
what I was doing, so based on the advice of the install program I
chose the big-file-install, which *was* what I wanted, but I forgot
that I had done that, so when I went to look at the exim config and
found, as the exim website told me I would find (because I was on
debian), a gazillion little bitty config files, I got started figuring
them out, editing them, and not realizing why it made no difference.
Suggestion to exim package people: if someone chooses the big config
file, don't even install the little ones.
Anyway, the point was not to complain about exim... it sounds like
other people are doing that somewhere else. The point was that
*whenever* debian package maintainers re-implement a well-known
distribution/config system, I *hope* that when users have to work with
it they will discover, as I am sure anyone using Henning's package
will, that the changes are clearly necessary -- an indisputable
improvement.
Now... my apologies for that interlude. I'll go back to lurking now.
I promise I won't respond to any further condescending comments.
Marc Haber
wrote:
>The Exim
>website gracefully acknowledged the Debian configuration mechanism as "elegant"
>and then advised that if I needed help with it, I should contact the
>debian distribution
>owners. Maybe I missed some great documentation out there, but using Google, I
>found no such documentation.
May I ask if you did the obvious thing, searching in /usr/share/doc?
Did you find the rather verbose README.Debian.gz file?
Tollef Fog Heen
| William Ballard writes:
| > The exim4 config asks you if you want itty bitty or one monolothic config
| > file. It offers you the option of doing it the upstream way.
|
| Does it tell you which is the upstream way? Most new users won't know.
The Debian exim4 packages can either use a single monolithic file
(/etc/exim4/exim4.conf.template) or about 40 small files in
/etc/exim4/conf.d/ to generate the final configuration.
.
The former is better suited for large modifications and is generally
more stable, whereas the latter offers a comfortable way to make
smaller
modifications but is more fragile and might break if modified
extensively.
.
If you are unsure then you should not use split configuration.
I think the last point sums it up -- use monolithic configuration if
you don't understand what the question is about.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Florian Weimer
> Is it really necessary to take our internal issues to upstream's
> mailing lists? Can't we have internal flamage internally?
Well, from time to time, many of us have an urgent desire to inflict
harm on the project. Maybe this was just one of the usual excesses?
I don't know.
There are many people who ridicule your heroic efforts as an exercise
in utterly pointless complexity, and, at the same time, many people
demand even more tweaks to serve their needs. Looks as if you found a
reasonable balance. 8-)
Brian May
John> Henning Makholm writes:
>> I maintain one package whose upstream author apparently thought that
>> $PATH would be a good place to look for a system-wide configuration
>> file. I changed that to look in /etc instead, which makes the
>> configuration mechanism in Debian substantially different from
>> upstream's.
John> I have made similar changes, but I also patched the documentation. Many
John> DDs do not do so, confusing users.
I consider that a bug.
If something like this is different, then not only should Debian
supplied documentation reflect the change, but a list of differences
should appear in README.Debian.
--
Brian May <b...@debian.org>
Thomas Bushnell BSG
I have found the exim-4 packages to be extremely well organized and
handy. I used to use the "one-file" method, and was simply delighted
when I found how easy it was to switch and tweak the individual files
that I needed to when I had to create a more complicated mail server.
Thomas
John Hasler
> I'm still not sure I understand it, but at for now I have it
> working). There was a substantial amount of hair pulling and cursing due
> to the disparity between what I saw on my hard drive and what I saw in
> the online documentation.
Why were you not referring to the Debian documentation? It has been (or
should have been) edited to reflect the "Debian way".
> domainlist local_domains = DEBCONFlocal_domainsDEBCONF
> How do I figure out where that DEBCONF stuff is coming from? What it
> means?
I suspect that those DEBCONF strings are flags for the debconf package
configuration system which should have been run during installation at
which point it would have set up the config for you after asking you some
questions. Either there is a bug or you did something strange.
--
John Hasler
Henning Makholm
> Henning Makholm writes:
>> I maintain one package whose upstream author apparently thought that
>> $PATH would be a good place to look for a system-wide configuration
>> file. I changed that to look in /etc instead, which makes the
>> configuration mechanism in Debian substantially different from
>> upstream's.
> I have made similar changes, but I also patched the documentation. Many
> DDs do not do so, confusing users.
I agree that documentation has to be changed accordingly. Thought it
was too obvious to mention. :-)
--
Henning Makholm "No one seems to know what
distinguishes a bell from a whistle."
Blunt Jackson
>
> Why were you not referring to the Debian documentation? It has been (or
> should have been) edited to reflect the "Debian way".
>
Well... I guess I'm the typical dumb user in this case. I didn't know
the documentation was there! I use a command line interface only, as I
build out servers -- I don't install any gui at all. Typically I use
my laptop (not linux) to go online to find documentation on
applications, or work off the README's and INSTALL's and other
documentation that come in a tarball of source. It didn't occur to me
that apt-get was putting all that documentation on my hard drive for
me. Never even looked in this /usr/share/doc place. So... I guess I
have a lot more resources than I thought!
I'll just go hide under a rock now.
(But I still think there is some benefit from approximating the
upstream developer's installation conventions where reasonable and
appropriate.)
BTW: I have never found any of that documentation through the debian
web site. It would be fantastic if there were an easy way to reference
it through the web. Except, I suppose there is, I was just too dumb to
find it. Gulp.
-b
--
-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-:-
Emilio Jesús Gallego Arias
>I have found the exim-4 packages to be extremely well organized and
>handy. I used to use the "one-file" method, and was simply delighted
>when I found how easy it was to switch and tweak the individual files
>that I needed to when I had to create a more complicated mail server.
>
>
Me too, I think exim4 packages are very well done, keep the good work.
Regards,
Emilio, Debian user.
William Ballard
> it through the web. Except, I suppose there is, I was just too dumb to
> find it. Gulp.
I had a similar experience when I reported bugs in Unstable on the list
and was roundly flamed for not reading bug reports.
apt-listchanges is a great thing to install; it lists fresh changelog
info every time you update.
Donald J Bindner
> * John Hasler
> If you are unsure then you should not use split configuration.
>
> I think the last point sums it up -- use monolithic configuration if
> you don't understand what the question is about.
I've installed exim many many times, and that is absolutely the
first time I believe I have not completely read across the "not".
I found by experience that I disagreed with what I though the
developer was saying (although I guess it turns out that we agree
after all).
It seems to me that we should tell WHAT TO DO if you are
unsure, not what to avoid.
When you compile a kernel and check the help on a module, you'll
never find "If unsure, don't say Y." Something to think about...
Don
--
Don Bindner <dbin...@truman.edu>
Marc Haber
wrote:
>I put in the time to figure out
>the debian way of doing Exim (and I'm still not sure I understand it,
>but at for now I have it working).
Please file a bug against exim4-base stating which part of the
description in /usr/share/doc/exim4-base/README.Debian.gz needs
improving.
>Note that removing the debian packages did not remove all
>their config files
Are you talking about a --remove or a --purge?
>> Just because the configuration file is called /etc/exim4/exim4.conf
>> instead of /usr/exim/configure? Oh dear.
>
>No, it was the stuff like this that made me pull out my hair:
>
>domainlist local_domains = DEBCONFlocal_domainsDEBCONF
>
>How do I figure out where that DEBCONF stuff is coming from? What it means?
You read available docs.
>Suggestion to exim package people: if someone chooses the big config
>file, don't even install the little ones.
How do I do this with current dpkg?
>I promise I won't respond to any further condescending comments.
That is a bad thing.
Marc Haber
>If something like this is different, then not only should Debian
>supplied documentation reflect the change, but a list of differences
>should appear in README.Debian.
One thing I have learned in the last 24 hours is that people do not
bother to read available documentation, regardless of where it is
stored. You have to hurl it right into the user's face.
I begin to understand the blurb of rants that cdrecord prints on
invocation.
Andrew Suffield
> When you compile a kernel and check the help on a module, you'll
> never find "If unsure, don't say Y." Something to think about...
That's because the string is "If unsure, say N".
asuffield@cyclone:/usr/src/linux-2.6.10$ grep unsure * -r | grep Kconfig | egrep -c "say '?Y"
148
asuffield@cyclone:/usr/src/linux-2.6.10$ grep unsure * -r | grep Kconfig | egrep -c "say '?N"
366
So much for that theory. Testing it took no more than a couple of
minutes; you could have done that yourself and saved us all the time
of a couple of mails.
--
.''`. ** Debian GNU/Linux ** | Andrew Suffield
: :' : http://www.debian.org/ |
`. `' |
`- -><- |
Russ Allbery
> On Thu, Feb 17, 2005 at 09:04:59PM -0600, Donald J Bindner wrote:
>> When you compile a kernel and check the help on a module, you'll
>> never find "If unsure, don't say Y." Something to think about...
> That's because the string is "If unsure, say N".
> asuffield@cyclone:/usr/src/linux-2.6.10$ grep unsure * -r | grep Kconfig | egrep -c "say '?Y"
> 148
> asuffield@cyclone:/usr/src/linux-2.6.10$ grep unsure * -r | grep Kconfig | egrep -c "say '?N"
> 366
> So much for that theory. Testing it took no more than a couple of
> minutes; you could have done that yourself and saved us all the time
> of a couple of mails.
I think you may have missed Donald's point. As I read his original
message, you're confirming exactly what he was trying to drive at. "If
unsure, don't say Y" feels awkwardly backwards to me as well, compared to
"If unsure, say N." Both sentences are, of course, logically equivalent
if there are only two options, but I have to go through a small bit of
additional processing to understand what I should do when presented with
the first phrasing, and it leaves me with a vague wondering if I missed
some other third choice.
That's not even getting into the valid point raised by someone else,
namely that it's unfortunately easy to read right past the "don't" in the
"if unsure, don't say Y" phrasing. My eye, if I'm in a hurry, picks up on
"unsure" and "Y" in that sentence and I can easily see myself not paying
close enough attention to parse and understand all the connecting words.
Certainly, that's my problem for not being attentive enough, but it's
worth making it easier on the poor sap in a hurry. That effect is even
worse when the phrasing is more drawn-out, like "If X, you should not say
Y."
--
Russ Allbery (r...@stanford.edu) <http://www.eyrie.org/~eagle/>
Joel Aelwyn
> On Thu, Feb 17, 2005 at 09:04:59PM -0600, Donald J Bindner wrote:
> > When you compile a kernel and check the help on a module, you'll
> > never find "If unsure, don't say Y." Something to think about...
>
> That's because the string is "If unsure, say N".
>
> asuffield@cyclone:/usr/src/linux-2.6.10$ grep unsure * -r | grep Kconfig | egrep -c "say '?Y"
> 148
> asuffield@cyclone:/usr/src/linux-2.6.10$ grep unsure * -r | grep Kconfig | egrep -c "say '?N"
> 366
>
> So much for that theory. Testing it took no more than a couple of
> minutes; you could have done that yourself and saved us all the time
> of a couple of mails.
I think you may have missed his point. One of the principles of good UI
design is that you never almost never want to tell someone what *not* to
do, if it is is a situation where telling them what *to* do is equally
meaningful (and in this case, it is; "If unsure, say N" and "If unsure,
don't say Y" mean the same thing for a Y/N question).
The reasons for it are long and not all that interesting unless you happen
to be interested in the field, and I'm too tired to go dig up a good
reference on Google, but I'm fairly sure one could be found without too
much difficulty.
Whether 'Y' or 'N' is the correct default is irrelevant; there is a good
reason the string is "If unsure, say *" rather than being "If unsure, don't
say *".
--
Joel Aelwyn <fen...@debian.org> ,''`.
: :' :
`. `'
`-
Bernd Eckenfels
> I had a similar experience when I reported bugs in Unstable on the list
> and was roundly flamed for not reading bug reports.
reportbug is pretty helpfull here, however some packages do have a very
large list, so misssing an already reported bug can happen and is nothing we
should flame our users for.
Greetings
Bernd
Steve Greenland
> * John Hasler
>
> The Debian exim4 packages can either use a single monolithic file
> (/etc/exim4/exim4.conf.template) or about 40 small files in
> /etc/exim4/conf.d/ to generate the final configuration.
> .
> The former is better suited for large modifications and is generally
> more stable, whereas the latter offers a comfortable way to make
> smaller
> modifications but is more fragile and might break if modified
> extensively.
> .
> If you are unsure then you should not use split configuration.
>
> I think the last point sums it up -- use monolithic configuration if
> you don't understand what the question is about.
No where in the Debconf note does it say which is "the upstream way".
And does it default to "one big file"?
Steve
--
Steve Greenland
The irony is that Bill Gates claims to be making a stable operating
system and Linus Torvalds claims to be trying to take over the
world. -- seen on the net
Josselin Mouette
> No where in the Debconf note does it say which is "the upstream way".
This has nothing to do in a debconf note.
> And does it default to "one big file"?
Yes.
--
.''`. Josselin Mouette /\./\
: :' : josselin...@ens-lyon.org
`. `' jo...@debian.org
`- Debian GNU/Linux -- The power of freedom
Steve Greenland
> Le vendredi 18 f??vrier 2005 ?? 08:37 -0600, Steve Greenland a ??crit :
> > No where in the Debconf note does it say which is "the upstream way".
>
> This has nothing to do in a debconf note.
Sigh. Did you read the thread? W. Ballard wrote:
> The exim4 config asks you if you want itty bitty or one monolothic
> config file. It offers you the option of doing it the upstream way.
And J. Hassler asked:
> Does it tell you which is the upstream way? Most new users won't know.
At which point Tollef quoted the debconf question, and the answer is
"no, it doesn't."
And yes, it does belong there. It could easily add the something like:
The single monolithic file is the normal upstream configuration,
while the other choice is a Debian innovation that works better with
large installations or ISPs needing to support many virtual domains.
For newbies, this is the first MTA installation they will have ever
seen. Help 'em out, for Pete's sake.
Mike Hommey
(...)
> And yes, it does belong there. It could easily add the something like:
>
> The single monolithic file is the normal upstream configuration,
> while the other choice is a Debian innovation that works better with
> large installations or ISPs needing to support many virtual domains.
>
> For newbies, this is the first MTA installation they will have ever
> seen. Help 'em out, for Pete's sake.
Do newbies understand the concept of "upstream" ?
Mike
Florian Weimer
> And yes, it does belong there. It could easily add the something like:
>
> The single monolithic file is the normal upstream configuration,
> while the other choice is a Debian innovation that works better with
> large installations or ISPs needing to support many virtual domains.
But this isn't completely correct. Even the single-file configuration
differs conceptually from upstream because some of the options are
managed through Debconf. Some people still complain that this isn't
the upstream way.
Ron Johnson
> On Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland <ste...@moregruel.net> wrote:
> (...)
> > And yes, it does belong there. It could easily add the something like:
> >
> > The single monolithic file is the normal upstream configuration,
> > while the other choice is a Debian innovation that works better with
> > large installations or ISPs needing to support many virtual domains.
> >
> > For newbies, this is the first MTA installation they will have ever
> > seen. Help 'em out, for Pete's sake.
>
> Do newbies understand the concept of "upstream" ?
Yes. Or vaguely.
Depends on the level of newbieness.
--
-----------------------------------------------------------------
Ron Johnson, Jr.
Jefferson, LA USA
PGP Key ID 8834C06B I prefer encrypted mail.
"Don't tell me peace has broken out."
Bertolt Brecht
Jeroen van Wolffelaar
> And J. Hassler asked:
> > Does it tell you which is the upstream way? Most new users won't know.
>
> At which point Tollef quoted the debconf question, and the answer is
> "no, it doesn't."
>
> And yes, it does belong there.
I think a lot, if not most, Debian users do not care at all how upstream
does there stuff. So exim upstream puts the debian config in /usr/exim
by default, apache calls their binaries and config files httpd, and
upstream's cron doesn't have the concept of cron.d.
I'm running Debian, not LFS, gentoo or any other collection of upstream
sources without much changes. Debian uses external sources (upstream),
and changes it to behave like a Debian package. There's nothing wrong
documenting the changes in README.Debian or similar, but I don't think
that it should be required, and indeed, only cron of the three examples
I listed note this change in their documentation, for those really
interested, Debian distributes the diffs against upstream sources.
--Jeroen
--
Jeroen van Wolffelaar
Jer...@wolffelaar.nl (also for Jabber & MSN; ICQ: 33944357)
http://Jeroen.A-Eskwadraat.nl
Greg Folkert
> On Fri, 18 Feb 2005 10:01:45 +1100, Brian May <b...@debian.org> wrote:
> >If something like this is different, then not only should Debian
> >supplied documentation reflect the change, but a list of differences
> >should appear in README.Debian.
>
> One thing I have learned in the last 24 hours is that people do not
> bother to read available documentation, regardless of where it is
> stored. You have to hurl it right into the user's face.
>
> I begin to understand the blurb of rants that cdrecord prints on
> invocation.
Indeedly-do.
Many people cannot find it then. Some people just WANT THE ANSWER, don;t
wanna learn anything to mayhaps fix it easy in the future.
--
greg, gr...@gregfolkert.net
The technology that is
Stronger, better, faster: Linux
Greg Folkert
> On Thu, 17 Feb 2005 19:31:20 +0000, Henning Makholm <hen...@makholm.net> wrote:
> > Scripsit Blunt Jackson <bluu...@gmail.com>
> >
> > > As a general note, I find it annoying, frustrating, and confusing
> > > whenever ANY debian package has a substantially different
> > > installation or configuratin mechanism than the mechanism documented
> > > by the software publisher.
> >
> > Perhaps Debian is not the distribution for you, then. We have always
> > prioritized constistency across the entire Debian OS over adherence to
> > what upstream authors somehow chose to do.
>
> Obviously there's a balance. I wasn't looking for flames. I believe I
> did explain *why* debian was my distribution of choice even so.
>
> > I maintain one package whose upstream author apparently thought that
> > $PATH would be a good place to look for a system-wide configuration
> > file. I changed that to look in /etc instead, which makes the
> > configuration mechanism in Debian substantially different from
> > it's how Debian operates.
>
> And clearly, *this* is a scenario in which the upstream author was way
> outside the *unix* standard way of doing things. I'm not saying
> there's any clear-cut answer, other than to hope that both upstream
> developers and debian package maintainers use common sense.
>
> One distinction is in applications that the majority of users just
> want to work out of the box, and forget about. If I had to tweak the
> configuration of every application on my servers, I would be a
> frothing maniac. But there are some biggies, some very well known
> applications, that, when installed for any practical purpose,
> generally require somewhat sophisticated user oversight. Exim is one,
> Apache is another. Mysql is a third. I put in the time to figure out
> the debian way of doing Exim (and I'm still not sure I understand it,
> hair pulling and cursing due to the disparity between what I saw on my
> hard drive and what I saw in the online documentation.
Okay, then generate the "old fashioned"Huge config file with
--keepcomments and If you don't remove the banners for each file you
will know which on the baddy.
Also, if you need to re-order the routers (the only one out side of
routers that need ordering is acl) then it is easy to do by simply
changing the number/letters at the beginning of the files name.
I DO NOT see what is so different from /etc/exim4/exim4.conf as compared
to /var/lib/exim4/config.autogenerated, especially if you use
--keepcomments. there really *IS* no difference. The pieces are just
packaged in small manageable ones to aid in the updating of.
Docs especially are like that Phil Hazel doesn't update them every time
he bumps the release. Marc Haber and Andreas Metzler are doing a great
job with exim.
> After that
> experience, when I installed apache and mysql, and saw they were doing
> their own thing as well, I decided I didn't want to learn go through
> the same frustration with applications I already knew pretty well. I
> removed the debian packages, and compiled my own from the upstream
> developers. Note that removing the debian packages did not remove all
> their config files and so forth, there was a fair bit of manual
> cleanup afterwards -- but I'm not using the stable distribution, so I
> don't expect perfection.
>
> As for you, Florian's snide comment:
>
> > Just because the configuration file is called /etc/exim4/exim4.conf
> > instead of /usr/exim/configure? Oh dear.
>
> No, it was the stuff like this that made me pull out my hair:
>
> domainlist local_domains = DEBCONFlocal_domainsDEBCONF
>
> How do I figure out where that DEBCONF stuff is coming from? What it means?
When you use "update-exim4.conf --keepsettings" the generated fully
populated is available at /var/lib/exim4/config.autogenerated.
Also, any debconf setting are in the file:
update-exim4.conf.conf
things like DEBCONFlocal_domainDEBCONF is changed to the setting(s) in
that file. Also, one other thing, look at the main directory in the
config... it has about 3 files in it. Those three files are the
important ones that define "default actions" for exim to take. Many of
those are also can be managed by debconf as well.
> Of course, it didn't help that during the install I didn't quite know
> what I was doing, so based on the advice of the install program I
> chose the big-file-install, which *was* what I wanted, but I forgot
> that I had done that, so when I went to look at the exim config and
> found, as the exim website told me I would find (because I was on
> debian), a gazillion little bitty config files, I got started figuring
> them out, editing them, and not realizing why it made no difference.
> Suggestion to exim package people: if someone chooses the big config
> file, don't even install the little ones.
Why does it matter if they were installed or not? They weren't being
used. So you want Yet Another Package like:
exim4-config-glob
exim4-config-non-glob
exim4-daemon-heavy-glob
exim4-daemon-heavy-non-glob
exim4-daemon-light-glob
exim4-daemon-light-non-glob
exim4-common-glob
exim4-common-non-glob
exim4-really-really-just-the-common
exim4-doc-info-glob-a-few-revs-behind
exim4-doc-html-glob-a-few-revs-behind
exim4-doc-txt-glob-a-few-revs-behind
exim4-doc-info-non-glob-a-few-revs-behind
exim4-doc-html-old-glob-a-few-revs-behind
exim4-doc-txt-old-glob-a-few-revs-behind
exim4-doc-info-glob-
exim4-doc-html-glob-whats-new-supplement
exim4-doc-txt-glob-whats-new-supplement
exim4-doc-info-non-glob-whats-new-supplement
exim4-doc-html-old-glob-whats-new-supplement
exim4-doc-txt-old-glob-whats-new-supplement
exim4-bj-custom-wants-it-this-way
> Anyway, the point was not to complain about exim... it sounds like
> other people are doing that somewhere else. The point was that
> *whenever* debian package maintainers re-implement a well-known
> distribution/config system, I *hope* that when users have to work with
> it they will discover, as I am sure anyone using Henning's package
> will, that the changes are clearly necessary -- an indisputable
> improvement.
Clearly.
> Now... my apologies for that interlude. I'll go back to lurking now.
Okay.
> I promise I won't respond to any further condescending comments.
Oh, come on this *IS* Debian-Devel after all.
Over all the making of good stuff, means manageable. Debian use debconf
for the majority of things, SuSE uses Yast2, RedHat use 4500 little
configlets...
Others do it other ways.
The bigfile *IS* created, just not where you expect it to be.
Greg Folkert
> On Thu, 17 Feb 2005 12:16:24 -0500, Greg Folkert
> <gr...@gregfolkert.net> wrote:
> >Except I'd rather see --keepcomments as
> >default and changed to --removecomments. My only gripe, pretty minimal.
>
> And fixed soon. #295735.
Wow, I didn't even consider it a problem. I just edited the scripts to
do it by default.. :)
Now I don't have to.
Thanks Marc.
Josselin Mouette
> On 18-Feb-05, 09:06 (CST), Josselin Mouette <jo...@debian.org> wrote:
> > Le vendredi 18 f??vrier 2005 ?? 08:37 -0600, Steve Greenland a ??crit :
> > > No where in the Debconf note does it say which is "the upstream way".
> >
> > This has nothing to do in a debconf note.
>
> Sigh. Did you read the thread? W. Ballard wrote:
>
> > The exim4 config asks you if you want itty bitty or one monolothic
> > config file. It offers you the option of doing it the upstream way.
How is it relevant?
> And yes, it does belong there. It could easily add the something like:
>
> The single monolithic file is the normal upstream configuration,
> while the other choice is a Debian innovation that works better with
> large installations or ISPs needing to support many virtual domains.
>
> For newbies, this is the first MTA installation they will have ever
> seen. Help 'em out, for Pete's sake.
Such a question will never help them. Why the hell would a newbie care
of a package diverging from upstream (if he understands what an upstream
is)? The newbie wants a working installation, full stop. That's why this
question isn't high priority: it isn't even shown to the newbie.
And the fact exim4 diverges from upstream has *absolutely nothing* to do
in a debconf note. Debconf is here to promt users, not to document
changes. We have README.Debian and changelog.Debian for that.
Steve Greenland
> Such a question will never help them. Why the hell would a newbie care
> of a package diverging from upstream (if he understands what an upstream
> is)?
Jesus H. Christ. Read the original post to this thread. It was a
complaint about how the upstream docs were not consistent with the
debian config.
> And the fact exim4 diverges from upstream has *absolutely nothing* to do
> in a debconf note. Debconf is here to promt users, not to document
> changes.
But how would it hurt to say that choice A is more standard?
Thomas Bushnell BSG
> Jesus H. Christ. Read the original post to this thread. It was a
> complaint about how the upstream docs were not consistent with the
> debian config.
Huh? The original post AFAICT of this thread consisted of Marc Haber
complaining that it was inappropriate for Ian Jackson to complain
about Debian's packaging on the exim-users upstream mailing list.
Ian Jackson's complaint in that thread had nothing to do with
documentation, AFAICT.
Marc Haber also referenced a bug, number #295391, reported by Ian
Jackson which appears to have started this, and in this bug, Ian is
complaining that when you ask for the one-file configuration, you
still see the tools for the many-file configuration installed. Ian
misunderstood what the exim package was doing; requesting the
single-file method does in fact get you the single-file method; he
incorrectly thought that this meant that /etc/exim4 shouldn't have
the other files in it at all.
He also reported a separate bug in the same bug report. Most of the
discussion in the bug log consists of Ian insisting that the way to
fix the bug he was seeing was to throw out whatever Debian was doing.
He also deleted exim from his machine and switch to smail, so it
became impossible to track down whatever the second bug was, as it
does not occur for the developer.
It reads rather like Ian throwing a tantrum, complaining that his
proposed solution ("this abomination should be thrown away and
rewritten") wasn't being taken seriously, and refusing to help find a
fix to the bug.
And then, taking his fight to the exim-users mailing list too.
Still, one piece of useful advice has come from the thread: that the
installation comment should tell the user what to do, rather than what
not to do.
Thomas
Thomas Bushnell BSG
> > And the fact exim4 diverges from upstream has *absolutely nothing* to do
> > in a debconf note. Debconf is here to promt users, not to document
> > changes.
>
> But how would it hurt to say that choice A is more standard?
What is "more standard"? I think everyone agrees (am I wrong?) that
the question should say: "if you don't know which to pick, then pick
the single-file method."
Josselin Mouette
> > And the fact exim4 diverges from upstream has *absolutely nothing* to do
> > in a debconf note. Debconf is here to promt users, not to document
> > changes.
>
> But how would it hurt to say that choice A is more standard?
More standard for what? AFAIK, Debian is the only widespread operating
system which ships exim by default. What the exim maintainers decide
becomes the standard for Debian users.
Furthermore, how does a thing being "standard" help the user in his
choice? The user only thinks of his own needs, thus a correct wording
would be "pick A if you don't care". However the current wording is even
better; the question isn't even asked at high priority, and the single
file method is silently chosen.
William Ballard
> Furthermore, how does a thing being "standard" help the user in his
> choice? The user only thinks of his own needs, thus a correct wording
> would be "pick A if you don't care". However the current wording is even
> better; the question isn't even asked at high priority, and the single
> file method is silently chosen.
Is the multiple-file configuration logically equivalent to the
single-file configuration? If you #include'd all the tiny subfiles,
would the resulting config be identical to the single-file config?
If so, then what are we really arguing about: they are isomorphic.
Perhaps a tool could generate the single-file config for easier
double-checking of the split-file config.
If not, then the user needs to know what will behave differently.
Stephen Gran
> On Sat, Feb 19, 2005 at 03:02:00AM +0100, Josselin Mouette wrote:
> > Furthermore, how does a thing being "standard" help the user in his
> > choice? The user only thinks of his own needs, thus a correct
> > wording would be "pick A if you don't care". However the current
> > wording is even better; the question isn't even asked at high
> > priority, and the single file method is silently chosen.
>
> Is the multiple-file configuration logically equivalent to the
> single-file configuration? If you #include'd all the tiny subfiles,
> would the resulting config be identical to the single-file config?
>
> If so, then what are we really arguing about: they are isomorphic.
> Perhaps a tool could generate the single-file config for easier
> double-checking of the split-file config.
>
> If not, then the user needs to know what will behave differently.
The only difference, AFAICT, is that when you pick the split file
option, the split files are concattenated together on /etc/init.d/exim4
{stop,restart,reload} (this is really handled by update-exim4.conf, but
that is irrelevant to the user perspective, IMHO). They produce the
same initial configuration in any case. The only difference from a user
experience is knowing that split files vs. monolithic is really related
to what to edit, rather than where configuration is read at runtime.
--
-----------------------------------------------------------------
| ,''`. Stephen Gran |
| : :' : sg...@debian.org |
| `. `' Debian user, admin, and developer |
| `- http://www.debian.org |
-----------------------------------------------------------------
William Ballard
> that is irrelevant to the user perspective, IMHO). They produce the
> same initial configuration in any case. The only difference from a user
Good lord, what are we arguing about then :-)
Do people who edit their exim config (I never do on my desktop)
really have a hard time grasping #include files?
Thomas Bushnell BSG
> Good lord, what are we arguing about then :-)
> Do people who edit their exim config (I never do on my desktop)
> really have a hard time grasping #include files?
You've missed the point of the many-small-files config. As a happy
user, let me explain what it's about.
The point is that I want to massage some parts of the configuration
and not others. I want the others to continue to get updated by the
normal package installation process.
If I use the one-big-file method, I can't really do this. I would
modify parts of the file, but then I can either install the new file
or not when the package updates it. It's a PITA, to merge every time
a small change is made in some other part of such a large config file.
So the many-small-files is perfect for a site like mine. Many changes
aren't even changes that get noticed by dpkg, because they involve
making new files to specify new router rules, for example. They just
get automatically put into the generated config file. And by
contrast, when nearly any change is made by the Debian package, it
just automatically goes into the new version without the need for me
to hand-edit the changes.
Really big sites will have their own config files anyway, so nothing
done by Debian matters much to them. Small and ordinary sites may be
happy with the default big file, because they never need to modify it
anyway. But middling sites, or sites like mine with small variations
on the normal model (in my case, I have a second domain that I MX for
through a special alias file) find the many-small-files just perfect.
Thomas
Stephen Gran
> The point is that I want to massage some parts of the configuration
> and not others. I want the others to continue to get updated by the
> normal package installation process.
>
> If I use the one-big-file method, I can't really do this. I would
> modify parts of the file, but then I can either install the new file
> or not when the package updates it. It's a PITA, to merge every time
> a small change is made in some other part of such a large config file.
I wanted to mention that I completely agree with this sentiment. We run a
couple of mail clusters, and we manage many single mail servers. Thanks
to the split file approach, we can ship a couple of custom config files
that allows us to tweak everything we need with a few macros and ifdef's.
We still get the nice package management and improvement of routers and
transports and all the rest of it.
My only point in the previous mail is that there really is no difference
in what is happening at run time - the only thing the end user has to
know is that they when they pick one setting, they make edits here, and
if they choose the other, they make edits there.
William Ballard
> William Ballard <nospam...@alltel.net> writes:
>
> > Good lord, what are we arguing about then :-)
> > Do people who edit their exim config (I never do on my desktop)
> > really have a hard time grasping #include files?
>
> You've missed the point of the many-small-files config. As a happy
> user, let me explain what it's about.
I use them too. I never my exim config at all, so I read the debconf
note and chose the many small files option. I think you misunderstood
my post. I said something like "who would be confused by what is in
essence #include files?"
Please spare me your moralizing when you don't even read my post very
closely and I was already in favor of the current way Debian handles it.
Sheesh.
Thomas Bushnell BSG
> Please spare me your moralizing when you don't even read my post very
> closely and I was already in favor of the current way Debian handles it.
I wasn't moralizing; I'm sorry if I misunderstood your note. Many
people here have failed to understand the point of the
many-small-files option, so I figured that a more complete explanation
would be independently useful.
I misunderstood you to be saying that since the two methods (when you
make no modifications) produce the same results, those of us who like
the many-small-files version should just use includes instead. But I
see now that you weren't saying that.
Thomas
Henning Makholm
> The point is that I want to massage some parts of the configuration
> and not others. I want the others to continue to get updated by the
> normal package installation process.
So is the whole thing essentially a workaround for dpkg's current
lack of good conffile update management, or would you still prefer the
separate files way if dpkg magically gained a well-tested and stable
conflict resolution scheme with bells, whistles, and 3-way merges?
--
Henning Makholm "Gå ud i solen eller regnen, smil, køb en ny trøje,
slå en sludder af med købmanden, puds dine støvler. Lev!"
Thomas Bushnell BSG
> Scripsit Thomas Bushnell BSG <t...@becket.net>
>
> > The point is that I want to massage some parts of the configuration
> > and not others. I want the others to continue to get updated by the
> > normal package installation process.
>
> So is the whole thing essentially a workaround for dpkg's current
> lack of good conffile update management, or would you still prefer the
> separate files way if dpkg magically gained a well-tested and stable
> conflict resolution scheme with bells, whistles, and 3-way merges?
Um, no, I don't think I said that. When I say, "this is an important
thing that X provides", you cannot go and assume that I mean "this is
the only reason to like X."
Marc Haber
<nospam...@alltel.net> wrote:
>Is the multiple-file configuration logically equivalent to the
>single-file configuration? If you #include'd all the tiny subfiles,
>would the resulting config be identical to the single-file config?
The single file configuration template is generated on package build
time from the same directory that ends up as the source for the
multiple-file configuration. That generation process can be repeated
on demand on the target system (update-exim4.conf.template).
The actual config file is being generated on he target system at run
time either from the single file configuration template or the
multiple-file configuration, depending on the debconf setting.
So I'd say they're pretty much equivalent.
>If so, then what are we really arguing about: they are isomorphic.
>Perhaps a tool could generate the single-file config for easier
>double-checking of the split-file config.
That tool is already there.
Greetings
Marc
--
-------------------------------------- !! No courtesy copies, please !! -----
Marc Haber | " Questions are the | Mailadresse im Header
Mannheim, Germany | Beginning of Wisdom " | http://www.zugschlus.de/
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 621 72739834
Marc Haber
wrote:
>Still, one piece of useful advice has come from the thread: that the
>installation comment should tell the user what to do, rather than what
>not to do.
Fixing this is unfortunately a non-option for sarge.
|[11/510]mh@lefler:~/chroot/sid-exim4/home/mh/exim4/trunk$ find debian/po -name '*.po' | wc -l
|40
|[12/511]mh@lefler:~/chroot/sid-exim4/home/mh/exim4/trunk$
The translators would kill us for doing that to them at this stage of
the release.
Marc Haber
wrote:
>So the many-small-files is perfect for a site like mine. Many changes
>aren't even changes that get noticed by dpkg, because they involve
>making new files to specify new router rules, for example. They just
>get automatically put into the generated config file. And by
>contrast, when nearly any change is made by the Debian package, it
>just automatically goes into the new version without the need for me
>to hand-edit the changes.
Another advantage of the multiple-file approach is that other packages
which need to receive e-mail (mailman, request-tracker, cabot for
example) could simply drop their transport/router combination into
/etc/exim4/conf.d and have them picked up by exim automatically. There
is currently no package doing this, but the possibility is there.
The disadvantage is that all packages dropping configuration bits into
/etc/exim4/conf.d need to coordinate a little bit, since exim does not
like configuration options being specified multiple times (having an
option twice is an error, instead of adding both values, or have a
first-served or a last-served approach). So, if exim4-config has
/etc/exim4/conf.d/routers/300_exim4-config_mailman specifying a router
called "mailman", and mailman suddenly starts bringing its own mailman
router in /etc/exim4/conf.d/routers/300_mailman_mailman, exim will
break because there are two mailman routers.
>Really big sites will have their own config files anyway, so nothing
>done by Debian matters much to them.
Really big sites will probably roll their own exim4-config package if
they bother to see what advantages that will bring to them.
Marc Haber
<hen...@makholm.net> wrote:
>So is the whole thing essentially a workaround for dpkg's current
>lack of good conffile update management,
basically, yes, but I prefer to say that it is an approach that
enables Debian to make use of the excellent dpkg conffile management.
Actually, part of myself being very disturbed was being flamed for
this by the man who actually designed dpkg and the conffile management
himself.
>or would you still prefer the
>separate files way if dpkg magically gained a well-tested and stable
>conflict resolution scheme with bells, whistles, and 3-way merges?
That would depend on the shape and sound of the bells and whistles.
The current approach works fine without user intervention, while with
a 3-way-merge-approach I suspect more manual intervention. The
multiple-file approach nicely gives hints about the scope of a change.
The bells and whistles would also need to include mechanisms to allow
dropping the ban on maintainer scripts modifying dpkg-conffiles,
including dpkg-conffiles belonging to other packages.
Christian Perrier
Sure. Changing an important screen with 36 complete translations just
now is an easy thing to do.
People who argue for this "easy change" are just volunteering to
handle translation updates and bring them back to the state they are
now if this thread happens to force Marc and Andreas to change the
template.
It is here since months if not years and now someone wakes up and
request for changes. Are we really trying to release a distribution?
Tollef Fog Heen
| Scripsit Thomas Bushnell BSG <t...@becket.net>
|
| > The point is that I want to massage some parts of the configuration
| > and not others. I want the others to continue to get updated by the
| > normal package installation process.
|
| So is the whole thing essentially a workaround for dpkg's current
| lack of good conffile update management, or would you still prefer the
| separate files way if dpkg magically gained a well-tested and stable
| conflict resolution scheme with bells, whistles, and 3-way merges?
It's also a nice way for other packages to update exim's configuration
-- I'm considering shipping files for mailman, for instance. It would
be nice if SA did the same and so on.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Ola Lundqvist
On Fri, Feb 18, 2005 at 02:42:56PM -0600, Ron Johnson wrote:
> On Fri, 2005-02-18 at 21:37 +0100, Mike Hommey wrote:
> > On Fri, Feb 18, 2005 at 02:15:16PM -0600, Steve Greenland <ste...@moregruel.net> wrote:
> > (...)
> > > And yes, it does belong there. It could easily add the something like:
> > >
> > > The single monolithic file is the normal upstream configuration,
> > > while the other choice is a Debian innovation that works better with
> > > large installations or ISPs needing to support many virtual domains.
> > >
> > > For newbies, this is the first MTA installation they will have ever
> > > seen. Help 'em out, for Pete's sake.
> >
> > Do newbies understand the concept of "upstream" ?
>
> Yes. Or vaguely.
No they don't. Even some experienced unix persons don't do that. It is
a word related much to debian.
With experience from a couple of hundred bug submitters I can tell that
many do not know what upstream is. They may vaguely understand it but
I have explained it many times. So I actually think the current wording
is a lot better. And it IS THE DEFAULT!
Regards,
// Ola
> Depends on the level of newbieness.
>
> --
> -----------------------------------------------------------------
> Ron Johnson, Jr.
> Jefferson, LA USA
> PGP Key ID 8834C06B I prefer encrypted mail.
>
> "Don't tell me peace has broken out."
> Bertolt Brecht
>
>
> --
> To UNSUBSCRIBE, email to debian-dev...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
>
>
--
--------------------- Ola Lundqvist ---------------------------
/ op...@debian.org Annebergsslingan 37 \
| op...@lysator.liu.se 654 65 KARLSTAD |
| +46 (0)54-10 14 30 +46 (0)70-332 1551 |
| http://www.opal.dhs.org UIN/icq: 4912500 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
Tore Anderson
> It's also a nice way for other packages to update exim's configuration
> -- I'm considering shipping files for mailman, for instance. It would
> be nice if SA did the same and so on.
But you'd do it so that the routers/transports you add are disabled by
default, right? I would consider it outright evil to change the generated
configuration the Exim binary use, when you cannot be sure if the user has
changed other files under conf.d/.
--
Tore Anderson
Marc Haber
wrote:
>* Tollef Fog Heen
> > It's also a nice way for other packages to update exim's configuration
> > -- I'm considering shipping files for mailman, for instance. It would
> > be nice if SA did the same and so on.
>
> configuration the Exim binary use, when you cannot be sure if the user has
> changed other files under conf.d/.
If people change the configuration, they will have to bear with
breakage this has caused. I would consider it a feature to have
mailman work immediately after installation on a default system, and
the exim4 configuration scheme has explicitly invented with that
possibility in mind.
Andreas Barth
> Marc writes:
> > I would consider it a feature to have mailman work immediately after
> > installation on a default system, and the exim4 configuration scheme has
> > explicitly invented with that possibility in mind.
> I would consider it an obnoxious bug for the installation of a package to
> alter my email configuration. At least make enabling the change a Debconf
> question.
why, in the default case? Is it also an "obvious bug" to change your
apache configuration?
Cheers,
Andi
--
http://home.arcor.de/andreas-barth/
PGP 1024/89FB5CE5 DC F1 85 6D A6 45 9C 0F 3B BE F1 D0 C5 D1 D9 0C
John Hasler
> I would consider it a feature to have mailman work immediately after
> installation on a default system, and the exim4 configuration scheme has
> explicitly invented with that possibility in mind.
I would consider it an obnoxious bug for the installation of a package to
alter my email configuration. At least make enabling the change a Debconf
question.
--
John Hasler
Tollef Fog Heen
| * Tollef Fog Heen
|
| > It's also a nice way for other packages to update exim's configuration
| > -- I'm considering shipping files for mailman, for instance. It would
| > be nice if SA did the same and so on.
|
| But you'd do it so that the routers/transports you add are disabled by
| default, right?
No. If you have exim4 installed and install mailman, it's a
reasonable expectation that you want to use those two together.
| I would consider it outright evil to change the generated
| configuration the Exim binary use, when you cannot be sure if the
| user has changed other files under conf.d/.
It will be documented in NEWS.Debian ifwhen I get around to it.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-
Frank Küster
> On 18 Feb 2005 17:54:42 -0800, Thomas Bushnell BSG <t...@becket.net>
> wrote:
>>Still, one piece of useful advice has come from the thread: that the
>>installation comment should tell the user what to do, rather than what
>>not to do.
>
> Fixing this is unfortunately a non-option for sarge.
>
> |[11/510]mh@lefler:~/chroot/sid-exim4/home/mh/exim4/trunk$ find debian/po -name '*.po' | wc -l
> |40
> |[12/511]mh@lefler:~/chroot/sid-exim4/home/mh/exim4/trunk$
>
> The translators would kill us for doing that to them at this stage of
> the release.
I don't know how these translation things are handled technically. But
since the intended meaning didn't change at all, I don't see why it is
better to have a "bad" english version and 40 equally "bad" translated
versions, over having a better english version, 10 better translated
versions, and 30 working translated versions with formally one
fuzzyness?
Regards, Frank
--
Frank Küster
Inst. f. Biochemie der Univ. Zürich
Debian Developer
Christian Perrier
> since the intended meaning didn't change at all, I don't see why it is
> better to have a "bad" english version and 40 equally "bad" translated
> versions, over having a better english version, 10 better translated
> versions, and 30 working translated versions with formally one
> fuzzyness?
One fuzzyness means the whole screen is shown in English.
So the choice is between a supposedly "perfect" English screen shown
to all users, no matter which language they prefer to use.....and 40
quite good screens which users may read in their own language.
The choice is also between translators happy to have achieved a full
process and have a complete translation in their language....and angry
teams because the templates have been broken again. Purely
psychological issue, sure....but that counts more than you may
imagine.
And, besides all this, a huge time wasting ot i18n coordinators trying
to get updates in by warning translators, then warn them again...then
make a status report to the package maintainers....usually two weeks
delay if we want to have the same translation ratio we had before the
change decision. I handled the last change with exim4 maintainers and,
believe me, that had a cost in matter of time.
Frank Küster
>> I don't know how these translation things are handled technically. But
>> since the intended meaning didn't change at all, I don't see why it is
>> better to have a "bad" english version and 40 equally "bad" translated
>> versions, over having a better english version, 10 better translated
>> versions, and 30 working translated versions with formally one
>> fuzzyness?
>
> One fuzzyness means the whole screen is shown in English.
Oh, sorry. I didn't think so far. But in fact in such case one could
fake the translation and simply unfuzzy it without making a change, of
course not before the unchanged file has been stored, and sent to the
translators.
No, it's not a good idea. Let's keep the change in mind for etch.
Marc Haber
wrote:
>At least make enabling the change a Debconf
>question.
Impossible with current policy since maintainer scripts are forbidden
to mess with dpkg-conffiles.
Christian Perrier
> No, it's not a good idea. Let's keep the change in mind for etch.
That, I fully agree with...:)
Tore Anderson
> No. If you have exim4 installed and install mailman, it's a
> reasonable expectation that you want to use those two together.
But you cannot know if I have changed, added, or removed files under
conf.d/ in such a way which would make your drop-in routers and
transports break the entire configuration. The files are after all
configuration the user is allowed to change as he pleases.
Policy 10.7.3 says:
Configuration file handling must conform to the following behavior:
* local changes must be preserved during a package upgrade, [..]
Even though you're not strictly changing _a_ configuration file by
dropping files under conf.d, you're changing the configuration that
Exim ends up reading. I've always felt that the general principle
that requirement is there for is something like "the user should be
able to trust us not to fuck around with his custom configuration
behind his back". And unless you ensure that the snippets belonging
to exim4-config isn't changed [in a significant way], you certainly
will violate that principle.
> It will be documented in NEWS.Debian ifwhen I get around to it.
As far as I know NEWS.Debian is only displayed on upgrades, so that
isn't sufficient. That said, documenting that you're doing something
undesireable isn't really an excuse for doing it in the first place.
Please consider putting the snippets somewhere else, like under
/etc/mailman/, and rather tell the user where to symlink them under
/etc/exim4/conf.d/.
--
Tore Anderson
Tore Anderson
> If people change the configuration, they will have to bear with
> breakage this has caused.
If the users cannot safely change Exim's configuration (save using the
Debconf scripts), it cannot be considered "configuration" by any Debian
standard I have ever seen. And if so, /etc is certinly not the right
place for it.
I really hope you didn't mean it the way I interpreted you..
Tollef Fog Heen
| * Tollef Fog Heen
|
| > No. If you have exim4 installed and install mailman, it's a
| > reasonable expectation that you want to use those two together.
|
| But you cannot know if I have changed, added, or removed files under
| conf.d/ in such a way which would make your drop-in routers and
| transports break the entire configuration. The files are after all
| configuration the user is allowed to change as he pleases.
Yes, he might for instance remove the files added by mailman and add
his own.
| Policy 10.7.3 says:
|
| Configuration file handling must conform to the following behavior:
|
| * local changes must be preserved during a package upgrade, [..]
|
| Even though you're not strictly changing _a_ configuration file by
| dropping files under conf.d, you're changing the configuration that
| Exim ends up reading.
Yes, and that's allowed. That's half the point of conf.d, AIUI.
[...]
| > It will be documented in NEWS.Debian ifwhen I get around to it.
|
| As far as I know NEWS.Debian is only displayed on upgrades, so that
| isn't sufficient. That said, documenting that you're doing something
| undesireable isn't really an excuse for doing it in the first place.
It's not undesireable -- it's very much desired. It makes Mailman and
Exim operate better together out of the box. Yes, it might break
custom configurations where the admin doesn't check his stuff
properly, but that's a fault of the admin, not the package.
| Please consider putting the snippets somewhere else, like under
| /etc/mailman/, and rather tell the user where to symlink them under
| /etc/exim4/conf.d/.
The user can just remove them if he doesn't want them.
--
Tollef Fog Heen ,''`.
UNIX is user friendly, it's just picky about who its friends are : :' :
`. `'
`-