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 Development

 
 
LinkBack Thread Tools
 
Old 02-26-2009, 01:42 PM
Holger Levsen
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

retitle 508644 Sorting out mail-transport-agent mess
thanks

Hi,

I'd like to close/reassign this bug... :-)

A better description of what this bug is about can actually be read in
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474999 and the solution
would be to file bugs against those 8 packages (listed in #508644) which
depend on mail-transfer-agent instead of on "exim4 | mail-transfer-agent".

But as this would hardcode exim4 as the default MTA for Debian in a number of
packages, some better solutions have been proposed in
http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best
choice appearantly being <87ve1faria.fsf@frosties.localdomain> which
proposes that exim4 should provide default-mta, packages needing an MTA
should depend on default-mta | mail-transfer-agent and the other MTAs should
provide mail-transfer-agent. Then, if we want to change the default, we just
need to touch two packages.

As per policy I'd like to gather consensus on this before mass filing bugs.


regards,
Holger
 
Old 02-27-2009, 06:51 AM
Steve Langasek
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

On Thu, Feb 26, 2009 at 03:42:39PM +0100, Holger Levsen wrote:

> But as this would hardcode exim4 as the default MTA for Debian in a number
> of packages, some better solutions have been proposed in
> http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best
> choice appearantly being <87ve1faria.fsf@frosties.localdomain> which
> proposes that exim4 should provide default-mta, packages needing an MTA
> should depend on default-mta | mail-transfer-agent and the other MTAs should
> provide mail-transfer-agent. Then, if we want to change the default, we just
> need to touch two packages.

I agree that this is the best solution.

> As per policy I'd like to gather consensus on this before mass filing bugs.

Given that m-t-a is mentioned explicitly in policy, and that "default-mta"
will be a virtual package, I think this should be recorded in policy as well
- though if a clear consensus emerges on debian-devel, there's no need to go
through the policy process before filing bugs.

Also, I haven't seen the exim4 maintainers comment on this proposal until
now. Obviously we would want to get that package to Provide: default-mta
before filing bugs on other packages.

Cheers,
--
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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-27-2009, 07:48 AM
Holger Levsen
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

Hi Marc, hi Andreas,

On Freitag, 27. Februar 2009, Steve Langasek wrote:
> Also, I haven't seen the exim4 maintainers comment on this proposal until
> now. Obviously we would want to get that package to Provide: default-mta
> before filing bugs on other packages.

Could you please take a look at 508644 and comment. Thanks.


regards,
Holger
 
Old 02-27-2009, 10:43 PM
Steve Langasek
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

On Fri, Feb 27, 2009 at 09:46:15AM +0100, Giacomo A. Catenazzi wrote:
>> Given that m-t-a is mentioned explicitly in policy, and that "default-mta"
>> will be a virtual package, I think this should be recorded in policy as well
>> - though if a clear consensus emerges on debian-devel, there's no need to go
>> through the policy process before filing bugs.

> Hmmm. I partially agree, but then we have an unnecessary exception:
> such virtual packages must have only one "provider", or else there
> will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency
> is declared as first dependency [1].

>From the definition of the virtual package in question, it should have only
one provider at a time.

The problems caused by having more than one provider of default-mta are the
same as those caused by depending on mail-transport-agent alone. This is
not an argument against defining a default-mta virtual package, this is an
argument against having stupid bugs in the implementation.

> I would prefer to create a real empty package:
> default-mta (maybe in a source package debian-defaults), which depends
> on exim.

This unavoidably couples Debian's choice of a default MTA for users who
install the new release, to the behavior for users who are upgrading from a
previous release, because users who have such a 'default-mta' package
installed will find their MTA changed on dist-upgrade.

This was already discussed in the thread referenced by Holger.

> [1] policy 7.5 has only a note:
> : If you want to specify which of a set of real packages should be the default to satisfy
> : a particular dependency on a virtual package, you should list the real package as an
> : alternative before the virtual one.

> Probably we should be stricter.

Stricter about what? There are lots of cases where it's useful to have only
one package at a time provide a virtual package, and to have other packages
reference that virtual package on its own (think build-dependencies).

--
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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-27-2009, 11:25 PM
Steve Langasek
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

On Fri, Feb 27, 2009 at 10:32:51AM +0100, Giacomo A. Catenazzi wrote:
>> I would prefer to create a real empty package:
>> default-mta (maybe in a source package debian-defaults), which depends
>> on exim.

> BTW "mta" is IMHO wrong. In most of the cases (IIRC) programs needs
> only a "sendmail" program. Should we split the dependencies on real-mta and
> only on a sendmail provider.

I think that's well out of scope for the current discussion. This is the
definition of the 'mail-transport-agent' virtual package that's been used in
Debian for many years; I don't think it makes sense to change the virtual
package name because of a quibble over the proper definition of an "MTA".

> BTW we should also rule a minimal set of sendmail interface (which option
> should be implemented). Actually every "MTA" has different sets of
> sendmail options, but I don't yet know about problems.

In practice, we have the LSB definition of the interfaces that
/usr/sbin/sendmail have to support; all but one of the MTA packages in
Debian implement this interface (the odd duck is nullmailer, which
Conflicts: lsb for this reason...)

But perhaps that definition needs some help if popcon can't use it to
reliably send mail to multiple recipients?

--
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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-28-2009, 12:01 AM
Russ Allbery
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

Steve Langasek <vorlon@debian.org> writes:

> In practice, we have the LSB definition of the interfaces that
> /usr/sbin/sendmail have to support; all but one of the MTA packages in
> Debian implement this interface (the odd duck is nullmailer, which
> Conflicts: lsb for this reason...)
>
> But perhaps that definition needs some help if popcon can't use it to
> reliably send mail to multiple recipients?

Listing multiple addresses separated by commas feels like a sendmailism to
me. I'm surprised that doesn't break with lots of other MTAs. The
general interface is addresses separated by spaces, which is also the
documented sendmail command-line interface. (The sendmail man page
represents the syntax as "[ address ... ]".)

I think this was just a bug in popularity-contest that happened to go
unnoticed since sendmail runs command-line arguments through the same
parser that it applies to To: headers.

--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-28-2009, 05:45 PM
Steve Langasek
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

On Sat, Feb 28, 2009 at 06:32:45PM +0100, Giacomo Catenazzi wrote:
> >> Hmmm. I partially agree, but then we have an unnecessary exception:
> >> such virtual packages must have only one "provider", or else there
> >> will be problems (IIRC) on dpkg, apt or ddbuild, if such dependency
> >> is declared as first dependency [1].

> >>From the definition of the virtual package in question, it should have only
> > one provider at a time.

> And this is an exception,

No, it isn't.

> >> I would prefer to create a real empty package:
> >> default-mta (maybe in a source package debian-defaults), which depends
> >> on exim.

> > This unavoidably couples Debian's choice of a default MTA for users who
> > install the new release, to the behavior for users who are upgrading from a
> > previous release, because users who have such a 'default-mta' package
> > installed will find their MTA changed on dist-upgrade.

> What about an other level of indirection:
> package debian-mta: Depends: exim | mta-mail-transfer-agent
> I think this case will solve upgrades, and changing easily the mta
> (without causing a failed dependency).

I believe that would also work, but it seems unnecessarily complex compared
to the use of a virtual package.

--
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 Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-01-2009, 02:55 PM
Andreas Metzler
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

On 2009-02-27 Steve Langasek <vorlon@debian.org> wrote:
> On Thu, Feb 26, 2009 at 03:42:39PM +0100, Holger Levsen wrote:
[...]
>> http://lists.debian.org/debian-devel/2008/05/msg00381.html with the best
>> choice appearantly being <87ve1faria.fsf@frosties.localdomain> which
>> proposes that exim4 should provide default-mta, packages needing an
>> MTA should depend on default-mta | mail-transfer-agent and the
>> other MTAs should provide mail-transfer-agent. Then, if we want to
>> change the default, we just need to touch two packages.

> I agree that this is the best solution.

>> As per policy I'd like to gather consensus on this before mass filing bugs.

> Given that m-t-a is mentioned explicitly in policy, and that
> "default-mta" will be a virtual package, I think this should be
> recorded in policy as well - though if a clear consensus emerges on
> debian-devel, there's no need to go through the policy process
> before filing bugs.

> Also, I haven't seen the exim4 maintainers comment on this proposal
> until now. Obviously we would want to get that package to Provide:
> default-mta before filing bugs on other packages.

Hello,

[exim4 hat on]
Neither me nor Marc could come up with obvious problems in the
proposal. I doubt this is an importartant data point, though. I do
not think I am exceptionally qualified to find any problems (if
they exist). ;-)

We could have a exim4 upload implementing in sid this rather
quickly after receiving a go.

cu andreas
--
`What a good friend you are to him, Dr. Maturin. His other friends are
so grateful to you.'
`I sew his ears on from time to time, sure'



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-01-2009, 06:25 PM
Carsten Hey
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

On Sun, Mar 01, 2009 at 04:55:23PM +0100, Andreas Metzler wrote:
> We could have a exim4 upload implementing in sid this rather quickly
> after receiving a go.

In general I much prefer a virtual package over a real one but I think
we should wait a bit until the following issues are clarified:

On Fri, Feb 27, 2009 at 09:46:15AM +0100, Giacomo A. Catenazzi wrote:
> [1] policy 7.5 has only a note:
> | If you want to specify which of a set of real packages should be the
> | default to satisfy a particular dependency on a virtual package, you
> | should list the real package as an alternative before the virtual
> | one.

In my opinion it is a way better practise to first update the policy and
then adapt n packages instead of first change them in a way which is
possibly against the policy and expect the policy to be updated
accordingly.

RFC 2119 says:
| 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there
| may exist valid reasons in particular circumstances to ignore
| a particular item, but the full implications must be understood and
| carefully weighed before choosing a different course.

The policy uses "should" in this case, do we understand the full
implications of the proposed step carefully weighed before choosing
a different course? We are probably on a good way to do this but until
now at least I do not fully understand how apt and aptitude would handle
all proposed solutions and what all possible negative side effects are.

Among the problems we try to deal with the proposed solutions is, as
Daniel wrote in <494422E7.2060505@debian.org>, that apt (and/or
aptitude) take the alphabetically first package which provides foo and
installs that to fulfill the relation to the virtual package foo.

Knowing this leads to an possible answer to the following question:

On Fri, Feb 27, 2009 at 11:03:20AM -0800, Steve Langasek wrote:
> On Fri, Feb 27, 2009 at 10:37:19AM +0100, Adam Borowski wrote:
> > Assume that in squeeze, the default changes to exim5. With an
> > actual pseudopackage, someone having both lenny and squeeze (or
> > unstable) in apt's sources will have default-mta either from lenny
> > (->exim4) or from squeeze (->exim5).
> >
> > With mere "provides:" (a virtual package), you'd have a version of
> > both exim4 and exim5 that provides default-mta.
>
> And what problem do you believe the latter will cause, in practice?

I hope I'm wrong, but I think if apt would try to solve a dependency on
the virtual package default-mta provided by exim4 and exim5 it would,
according to Daniel's explanation and my own experience, choose to
install exim4 in the described case since it is the alphabetically first
package *1. On one of my stable desktops I still have oldstable in the
sources.list because I tried to isolate a bug using some packages from
oldstable, both oldstable and stable are pinned to 500. I obviously
don't want to install a mta from oldstable. A default-mta package would
to the right thing and install the mta from stable instead of the one
from oldstable since real packages work with pinning and have a version
number which ensures that the newest version of two equal-pinned
packages with the same name is installed.

There has been an argument that a real default-mta package would be
suboptimal because this would be equally to what we have now with gcc,
which leads to new packages (gcc-X.Y or eximZ) to be installed. This is
in my opinion wrong as gcc and its dependencies are completely different
to what has been proposed for the default-mta package. If you install
a default-mta package which depends on "exim4|mta" (I hope that has been
proposed, if not it should have been) and exim4 and then you upgrade
your default-mta package which now depends on "exim5|mta", the fact that
exim4 provides mta ensures that the dependencies of the new default-mta
package are satisfied and apt/aptitude would not, unless this part is
really messed up, try to install exim5.

Using virtual packages for now and hope apt/aptitude handle virtual
packages in a better way until exim5 will be the default mta could be
one possible course, but what happens when they do not? Mixing virtual
and real packages does not sound that good.

Unless I'm wrong and the virtual packages support is a lot better than
I think, it looks like main question is whether it is better to use
a real default-mta package or wait for apt and aptitude to be improved.


Regards
Carsten

*1 Or it uses the package from the first sources.list entry, I guess apt
would rather do this when the virtual package can be found in more
than one sources.list entry, but anyway, why apt might choose the
wrong entry is not really important now. Important is that we are
not sure that it would choose exim5 in this example.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 03-01-2009, 07:21 PM
Carsten Hey
 
Default Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta

On Sun, Mar 01, 2009 at 08:25:38PM +0100, Carsten Hey wrote:
> ... if apt would try to solve a dependency on the virtual package
> default-mta provided by exim4 and exim5 it would ... choose to install
> exim4 in the described case ...

In case of a virtual default-mta package, the existence of
a transitional package (exim did not have one in Etch) could prevent
a package from an older release to be installed, but it would still use
an old default and thus install a package that might be removed during
the next release cycle.


Carsten



--
To UNSUBSCRIBE, email to debian-devel-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 12:56 AM.

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