Re: Sorting out mail-transport-agent mess
On Thu August 21 2008 03:22:41 Steve Langasek wrote: On Fri, May 16, 2008 at 04:53:49AM +0200, Goswin von Brederlow wrote: Package exim4: Provides: default-mta Package: foo Depends: default-mta | mail-transport-agent This should be enough to single out one MTA as the one to be installed if in doubt and should not cause a change in who provides default-mta to suddenly install a different mta. Any reasons against that? Given that no one has come up with any objections to this in the past three months: no, this looks like a very good solution. No one objected to having apt decide by giving priority precedence over lexical: http://lists.debian.org/debian-devel/2008/05/msg00388.html The priority solution is more general and provides automatic consistency between defaults and priorities without creating unnecessary packages. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
[Mike Bird] No one objected to having apt decide by giving priority precedence over lexical: It sounds good until you notice just how many dependency resolvers we have floating around. dselect, apt, aptitude, pbuilder, sbuild - at least. Don't know if synaptic has its own or borrows from libapt. Without researching it, I'd say the 'default-mta' virtual package is more likely to work everywhere. And historically, it doesn't always pay to hold your breath waiting for both dpkg and apt to implement a new feature. -- Peter Samuelson | org-tld!p12n!peter | http://p12n.org/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Thu, Aug 21, 2008 at 02:07:43PM -0500, Peter Samuelson wrote: [Mike Bird] No one objected to having apt decide by giving priority precedence over lexical: It sounds good until you notice just how many dependency resolvers we have floating around. dselect, apt, aptitude, pbuilder, sbuild - at least. Don't know if synaptic has its own or borrows from libapt. Also, even if no one objected, no one has volunteered to implement this either. Amending apt's resolver to prefer packages with a higher priority is a good goal, but I don't think it should be a blocker for improving our m-t-a handling. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Fri, May 16, 2008 at 02:10:39AM +0200, Eugeniy Meshcheryakov wrote: 15 травня 2008 о 16:24 -0700 Steve Langasek написав(-ла): What concerns me about this approach is that it could easilly end up with dist-upgrades swapping out users mail systems without warning. I would consider such behaviour unacceptable as it could easilly cause mail loss Er, no, that wouldn't happen. As long as packages correctly depend on default-mta | mail-transport-agent, this will have no impact on upgrades. This can happen if user has 'default-mta' package installed, and it changes (if it is done like with 'gcc' package now). What if default-mta itself depend on the current default (exim4) | mail-transport-agent? Then future changes to default-mta would not affect installed users. ie: Package: something-that-needs-an-mta Depends: default-mta | mail-transport-agent Package: default-mta Depends: exim4-daemon-light | mail-transport-agent Hamish -- Hamish Moffatt VK3SB [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On a related note flashback,mode=bugs bunny If I dood it, I get a whipping. I dood it. /flashback What about the possibility of MTA/MSP alternatives - I'd like to support the next generation sendmail (Meta - used to be SM x) - a very postfix like design for enhanced security. I recall RH, or a deriviative that supported multiple MTAs being installed concurrently via alternatives. For quite a while, Meta was only usable for an outgoing MTA, and was missinge milter support (making it unusable, IMNSHO for inbound) so I did some prelimiary work to support this in the sendmail package, there would need be much infrastructure suppport to make this feasible. -- Rick Nelson Even more amazing was the realization that God has Internet access. I wonder if He has a full newsfeed? (By Matt Welsh) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
* Sune Vuorela | 3) do the real ugly hack and invent a a-m-t-a depending on the default mta FWIW, aa sorts together with å (after x, y, z, æ and ø (or ø and æ, in da_DK, I think)) in some locales, so that might not be the best choice. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Thu, 15 May 2008, Steve Langasek wrote: 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. +1 from me. I have also seen this precise suggestion been made on an Ubuntu list as well since they have postfix as default MTA. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Eugeniy Meshcheryakov, 2008-05-16 02:10:39 +0200 : This can happen if user has 'default-mta' package installed, and it changes (if it is done like with 'gcc' package now). Unless default-mta Depends: exim4 | mail-transport-agent. But that's a bit ugly. Roland. -- Roland Mas Fate always wins... At least, when people stick to the rules. -- in Interesting Times (Terry Pratchett) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Thu, May 15, 2008 at 04:45:19PM -0700, Steve Langasek wrote: 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. AOL -- Stefano Zacchiroli -*- PhD in Computer Science ... now what? [EMAIL PROTECTED],cs.unibo.it,debian.org} -%- http://upsilon.cc/zack/ (15:56:48) Zack: e la demo dema ?/\All one has to do is hit the (15:57:15) Bac: no, la demo scema\/right keys at the right time signature.asc Description: Digital signature
Re: Sorting out mail-transport-agent mess
Steve Langasek [EMAIL PROTECTED] writes: On Thu, May 15, 2008 at 11:33:04PM +0200, Sune Vuorela wrote: Noticing among others this bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322751 and observing the many packages depending on $MTA | mail-transport-agent with $MTA having values like postfix, exim, exim4, sendmail, nullmailer and probably others. And some packages just depending on mail-transport-agent without providing a preferred. The latter, just depending on mail-transport-agent, makes apt, at least currently, pick the package first in the alphabet providing m-t-a. (A bit ago, this was courier. now it is citadel). This definately needs fixing, but why not sort everything out while we are at it? I think something needs to be done somewhere. There is several solutions, among others the following: 1) Exim4 is currently the default installed MTA. So any package requiring a MTA should depend on exim4 | mail-transport-agent. Defined by policy and all packages should be fixed to this. 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. Anthony Towns did mention (WRT the inet-superserver virtual package) before the release of etch that there was some ongoing work to do something to specify the default for virtual packages globally (i.e. not needing an alternative dep in each and every package depending on a virtual package). This would make updating the defaults and writing the dependencies much simpler, and reduce any inconsistency between the alternative deps in each package. Does anyone know if there was any progress made on this in the meantime? At that time I did suggest creating a single package (virtual-defaults IIRC) which I prototyped. This implemented defaults for all packages, including the default-mta package (by a slightly different name), but the idea was rejected because (IIRC) of the untidiness of leaving a dummy package around when the reverse deps were removed. http://lists.debian.org/debian-devel/2006/09/msg00735.html (I can't see the replies in the archive, though.) Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `-GPG Public Key: 0x25BFB848 Please GPG sign your mail. pgpbPNeXT9wWD.pgp Description: PGP signature
Re: Sorting out mail-transport-agent mess
On Thu May 15 2008 14:33:04 Sune Vuorela wrote: The latter, just depending on mail-transport-agent, makes apt, at least currently, pick the package first in the alphabet providing m-t-a. (A bit ago, this was courier. now it is citadel). This definately needs fixing, but why not sort everything out while we are at it? All of the MTA's provide mail-transport-agent. I had assumed that apt would choose between them on the basis that exim4-daemon-light is the only provider with priority standard, the others being optional or extra. If apt does not consider package priorities in resolving disjunctions, a possible solution would be for apt to do so. --Mike Bird -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
re: Sorting out mail-transport-agent mess
2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. What concerns me about this approach is that it could easilly end up with dist-upgrades swapping out users mail systems without warning. I would consider such behaviour unacceptable as it could easilly cause mail loss if the user has a customised configuration. It seems to me that the ideal soloution would be to fix apt/the repositry system so that the defaults for a virtual package can be explicitly designed. Failing that how about a default-mta virtual package that is provided by *exactly one* real package. That way it is easy to change the default but upgrades should stay with the version that they have. Under that system changing the default MTA would require changes to two packages which seems manageable to me. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
peter green [EMAIL PROTECTED] writes: It seems to me that the ideal soloution would be to fix apt/the repositry system so that the defaults for a virtual package can be explicitly designed. I have no idea how to do this and no time to help, but I think this would be really cool and would solve a lot of annoying problems, particularly around transitions of the default for some alternative. -- Russ Allbery ([EMAIL PROTECTED]) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Thu, May 15, 2008 at 11:39:36PM +0100, peter green wrote: 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. What concerns me about this approach is that it could easilly end up with dist-upgrades swapping out users mail systems without warning. I would consider such behaviour unacceptable as it could easilly cause mail loss Er, no, that wouldn't happen. As long as packages correctly depend on default-mta | mail-transport-agent, this will have no impact on upgrades. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Mike Bird [EMAIL PROTECTED] writes: All of the MTA's provide mail-transport-agent. I had assumed that apt would choose between them on the basis that exim4-daemon-light is the only provider with priority standard, the others being optional or extra. If apt does not consider package priorities in resolving disjunctions, a possible solution would be for apt to do so. +1 This solution seems superior to my next choice, the introduction of a 'sensible-mta' package (to be used much as the OP's suggestion of 'default-mta'). -- \ Ice Water? Get some onions - that'll make your eyes water! | `\ -- Groucho Marx | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Thu, May 15, 2008 at 11:33:04PM +0200, Sune Vuorela wrote: Noticing among others this bug report http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=322751 and observing the many packages depending on $MTA | mail-transport-agent with $MTA having values like postfix, exim, exim4, sendmail, nullmailer and probably others. And some packages just depending on mail-transport-agent without providing a preferred. The latter, just depending on mail-transport-agent, makes apt, at least currently, pick the package first in the alphabet providing m-t-a. (A bit ago, this was courier. now it is citadel). This definately needs fixing, but why not sort everything out while we are at it? I think something needs to be done somewhere. There is several solutions, among others the following: 1) Exim4 is currently the default installed MTA. So any package requiring a MTA should depend on exim4 | mail-transport-agent. Defined by policy and all packages should be fixed to this. 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
15 травня 2008 о 16:24 -0700 Steve Langasek написав(-ла): What concerns me about this approach is that it could easilly end up with dist-upgrades swapping out users mail systems without warning. I would consider such behaviour unacceptable as it could easilly cause mail loss Er, no, that wouldn't happen. As long as packages correctly depend on default-mta | mail-transport-agent, this will have no impact on upgrades. This can happen if user has 'default-mta' package installed, and it changes (if it is done like with 'gcc' package now). signature.asc Description: Digital signature
Re: Sorting out mail-transport-agent mess
On Fri, May 16, 2008 at 02:10:39AM +0200, Eugeniy Meshcheryakov wrote: 15 травня 2008 о 16:24 -0700 Steve Langasek написав(-ла): What concerns me about this approach is that it could easilly end up with dist-upgrades swapping out users mail systems without warning. I would consider such behaviour unacceptable as it could easilly cause mail loss Er, no, that wouldn't happen. As long as packages correctly depend on default-mta | mail-transport-agent, this will have no impact on upgrades. This can happen if user has 'default-mta' package installed, and it changes (if it is done like with 'gcc' package now). Ah, ok. Yes, that's a possibility; I was only considering the case that a user had an MTA installed that was not the default. So the best option here does seem after all to get apt to look at package priorities when satisfying virtual packages. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Steve Langasek [EMAIL PROTECTED] writes: On Thu, May 15, 2008 at 11:33:04PM +0200, Sune Vuorela wrote: 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. If 'default-mta' is renamed to 'sensible-mta' to follow the existing convention (evidenced by 'sensible-editor', etc.), I agree. -- \ For every complex problem, there is a solution that is simple, | `\neat, and wrong. -- Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
On Fri, May 16, 2008 at 10:53:03AM +1000, Ben Finney wrote: Steve Langasek [EMAIL PROTECTED] writes: On Thu, May 15, 2008 at 11:33:04PM +0200, Sune Vuorela wrote: 2) Introduce a default-mta package (currently) depending on exim4. All packages requiring a MTA should depend on default-mta | mail-transport-agent. This will have the extra advantage that we (and others like CDDs and derived distros) easily could swap default MTA. I believe that 2) is the correct option, and can see no reason that it shouldn't be implemented straight away. If 'default-mta' is renamed to 'sensible-mta' to follow the existing convention (evidenced by 'sensible-editor', etc.), I agree. That's not at all consistent with how sensible-foo is used in Debian today. sensible-editor and sensible-browser are /commands/ that are guaranteed to be available for other packages to use and which respect the user- and site-preferences; default-mta is not at all like this. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developerhttp://www.debian.org/ [EMAIL PROTECTED] [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Steve Langasek [EMAIL PROTECTED] writes: sensible-editor and sensible-browser are /commands/ Provided by the 'debianutils' package. default-mta is not at all like this. You're right, I'm wrong. Thanks for clearing my confusion. -- \ Hey Homer! You're late for English! Pff! English, who needs | `\ that? I'm never going to England! -- Barney Homer, _The | _o__)Simpsons_ | Ben Finney -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Sorting out mail-transport-agent mess
Steve Langasek [EMAIL PROTECTED] writes: On Fri, May 16, 2008 at 02:10:39AM +0200, Eugeniy Meshcheryakov wrote: 15 ÑÑÐ°Ð²Ð½Ñ 2008 о 16:24 -0700 Steve Langasek напиÑав(-ла): What concerns me about this approach is that it could easilly end up with dist-upgrades swapping out users mail systems without warning. I would consider such behaviour unacceptable as it could easilly cause mail loss Er, no, that wouldn't happen. As long as packages correctly depend on default-mta | mail-transport-agent, this will have no impact on upgrades. This can happen if user has 'default-mta' package installed, and it changes (if it is done like with 'gcc' package now). Ah, ok. Yes, that's a possibility; I was only considering the case that a user had an MTA installed that was not the default. So the best option here does seem after all to get apt to look at package priorities when satisfying virtual packages. Package exim4: Provides: default-mta Package: foo Depends: default-mta | mail-transport-agent This should be enough to single out one MTA as the one to be installed if in doubt and should not cause a change in who provides default-mta to suddenly install a different mta. Any reasons against that? MfG Goswin PS: This is not to say apt shouldn't also be fixed to look at priorities but that is a longer process. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
