Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
 

Steve Langasek wrote:

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.


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].

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

ciao
cate


[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.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
 

Giacomo A. Catenazzi wrote:

Steve Langasek wrote:

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.


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].

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.

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.

ciao
cate




--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
 

On Thu, Feb 26, 2009 at 11:51:39PM -0800, Steve Langasek wrote:
> 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.

The referred post mentions an actual package rather than just a "provides:"
field. It makes a difference.
>
> Given that m-t-a is mentioned explicitly in policy, and that "default-mta"
> will be a virtual package,

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.


Rawr?!?
--
1KB // Microsoft corollary to Hanlon's razor:
// Never attribute to stupidity what can be
// adequately explained by malice.


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

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:
> Giacomo A. Catenazzi wrote:
> 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.
>
> 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.

Well there were some problems with popularity-contest, see bug #326593
IIRC for sending to both foo@example.com and bar@example.com:
ssmtp allows
sendmail -oi foo@example.com,bar@example.com
but not courrier-mta which want
sendmail -oi foo@example.com bar@example.com

Another issue for popularity-contest is that MTA that do not retry on
error do not provide much avantage over HTTP submission. However
popularity-contest does not need that the MTA listen on port 25.

Cheers,
--
Bill. <ballombe@debian.org>

Imagine a large red swirl here.



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
 

On Fri, Feb 27, 2009 at 10:37:19AM +0100, Adam Borowski wrote:
> On Thu, Feb 26, 2009 at 11:51:39PM -0800, Steve Langasek wrote:
> > 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.

> The referred post mentions an actual package rather than just a "provides:"
> field.

No, not the Message-Id that Holger referenced.

http://lists.debian.org/msgid-search/87ve1faria.fsf@frosties.localdomain

> It makes a difference.

Yes, it does; and that thread identified what the differences are that
should cause us to prefer a virtual package instead of a real one.

http://lists.debian.org/debian-devel/2008/05/msg00390.html

> 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?

--
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

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
 

Steve Langasek wrote:
> 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.

And this is an exception, which I want to avoid. So let try to work
around with "normal package". If we fail, I agree with the virtual package.


>> 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).

ciao
cate





--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
 

Am 2009-02-27 19:34:04, schrieb Bill Allombert:
> Well there were some problems with popularity-contest, see bug #326593
> IIRC for sending to both foo@example.com and bar@example.com:
> ssmtp allows
> sendmail -oi foo@example.com,bar@example.com
> but not courrier-mta which want
> sendmail -oi foo@example.com bar@example.com

This was one of the things which screwed me...

But, why not using sendmails "-t" option which work for ssmtp, courier,
exim and postfix?

You have to write the WHOLE mail including all headers and pipe it into
"${MTA} -t"

> Another issue for popularity-contest is that MTA that do not retry on
> error do not provide much avantage over HTTP submission.

Are you sure it does not retry?
I think, it depends WHICH MTA you are using.

Thanks, Greetings and nice Day/Evening
Michelle Konzack
Systemadministrator
24V Electronic Engineer
Tamay Dogan Network
Debian GNU/Linux Consultant


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
<http://www.tamay-dogan.net/> <http://www.can4linux.org/>
Michelle Konzack Apt. 917 ICQ #328449886
+49/177/9351947 50, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France IRC #Debian (irc.icq.com)

Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
 

Steve Langasek wrote:

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.


why not?

Section 3.6:
: Sometimes, there are several packages which offer more-or-less the same functionality.
: In this case, it's useful to define a virtual package whose name describes that common
: functionality.

This is the rationale and the explanation of virtual package, which explicitly tell us
about "several package".

And MTA is not a special case: we have the same problem with syslog, possibly also
with inetd. In past we had IIRC mass bug reports on transition with modutils.



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.


IMO it the contrary: virtual package seems more complex to me.
Advantages:
- the default is set by an independent maintainer (release, policy, ...)
- easier (IMO) for custom distributions

But ok, it you think it is simpler with virtual packages, I'm ok also
with it.

ciao
cate



--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org