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

[Manoj Srivastava]

On Sun, Mar 01 2009, Carsten Hey wrote:

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

Actually, this is contrary to  the accepted practice that policy
 is not the place to do design; and that you should have a working,
 tested solution (by convincing and getting a the maintainers of
 affected packages to implement the solution); _then_ you write that in
 stone.

While there might not be much to design here in this particular
 case, you can't call on "better" practice, since policy has never
 worked that way.

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

Policy's use of should has little to do with the RFC 2119;
 indeed, it would need an almost full rewrite to make sure policy
 starts using RFC 2119 version of  SHOULD/MUST.

manoj
 starting to look at policy again
-- 
"Take that, you hostile sons-of-bitches!" James Coburn, in the finale of
_The_President's_Analyst_
Manoj Srivastava    
1024D/BF24424C print 4966 F272 D093 B493 410B  924B 21BA DABB BF24 424C


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Carsten Hey]

On Sun, Mar 01, 2009 at 09:44:41PM -0800, Steve Langasek wrote:
> You have a case here where the user has managed to run a complete
> system for a non-negligible period of time without ever installing an
> MTA (long enough to either configure oldstable in their sources.list,
> or for the version of Debian they installed to *become* oldstable).
>
> Then the user tries to install a package that depends/recommends
> default-mta | mail-transport-agent, and pulls in a default.  Why does
> the user care if this pulls in the one from oldstable vs. stable?

(Imagine that we did this default-mta-foo years ago)

He or she cares because the security support of exim will stop in less
than a year and exim4 is a much more sane default than exim, especially
for users who don't explicitly install their favorite mta since exim has
an ugly pre-debconf initial configuration system.  Also remember, that
there is no upgrade path from exim to exim4 (release notes do not count
here since the user read them months ago when he or she did the
dist-upgrade and no one can expect that users remember every side note
in them during the whole release cycle) and that the user can expect to
to able to remove the old souces.list entry without bad things like no
security support for their mta happening (he or she did already do
a dist-upgrade with the release notes in mind).  I'm not sure if there
are many users who put oldstable and stable during an dist-upgrade in
their sources.list, but these are also affected by this when a package
they use changed its dependency during the last release cycle to include
mta or APT::Install-Recommends is set to yes.

> Ok, if the package in question also exists in stable, then installing
> the oldstable version means the package will be immediately
> out-of-date and it will have to be upgraded on the next apt-get run.

I think in this case apt would directly install the exim package in
stable, i.e. a transitional package (which does not exist for exim).

> It does somewhat complicate the dependency graph to have a package
> with numerous reverse-deps adding an or'ed dependency; this could
> cause some pain to tools that process package dependencies (not just
> apt - I'm specifically thinking of britney here), using a virtual
> package and ignoring this case.  But that's just speculation at this
> point.

I have no idea whether britney would handle virtual or real default-mta
packages in a better way, ftpmaster should be able to answer this if it
really matters.  Deborphan for example currently handles virtual
packages in a suboptimal way (although no false positives are caused by
them) but this can be fixed.  Maybe one could think about a release goal
"handle virtual packages in a sane way"?


Regards
Carsten


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

On Sun, Mar 01, 2009 at 08:25:38PM +0100, Carsten Hey wrote:
> Among the problems we try to deal with the proposed solutions is, as
> Daniel wrote in <494422e7.2060...@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.

Sorry, I don't think this is obvious at all, which is why I asked what the
practical problems are.

You have a case here where the user has managed to run a complete system for
a non-negligible period of time without ever installing an MTA (long enough
to either configure oldstable in their sources.list, or for the version of
Debian they installed to *become* oldstable).  Then the user tries to
install a package that depends/recommends default-mta | mail-transport-agent,
and pulls in a default.  Why does the user care if this pulls in the one
from oldstable vs. stable?  Ok, if the package in question also exists in
stable, then installing the oldstable version means the package will be
immediately out-of-date and it will have to be upgraded on the next apt-get
run.  But in terms of an overall policy, if the user hasn't selected an MTA,
*and* has configured their sources.list such that multiple packages
providing default-mta are available, I don't see any reason that it matters
whether the user gets the old default vs. the new default.

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

Yes, you're right that a default-mta that Depends: exim4 | m-t-a would
address this.  So if there's a sense that this is worth addressing, then I'm
ok with that.

It does somewhat complicate the dependency graph to have a package with
numerous reverse-deps adding an or'ed dependency; this could cause some pain
to tools that process package dependencies (not just apt - I'm specifically
thinking of britney here), and if it did I would come down on the side of
using a virtual package and ignoring this case.  But that's just
speculation at this point.

(BTW, I don't believe it was proposed before to use default-mta Depends:
exim4 | m-t-a, no.)

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

 mixing virtual and real packages happens all the time in the
archive. :)

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

I don't agree at all.  I don't see anything here that needs to be improved
before a virtual default-mta package would be acceptable.

-- 
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/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Giacomo A. Catenazzi]

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

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

[Michelle Konzack]

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 f...@example.com and b...@example.com: 
> ssmtp allows
> sendmail -oi f...@example.com,b...@example.com
>   but not courrier-mta which want
> sendmail -oi f...@example.com b...@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 #
   
Michelle Konzack   Apt. 917  ICQ #328449886
+49/177/935194750, rue de Soultz MSN LinuxMichi
+33/6/61925193 67100 Strasbourg/France   IRC #Debian (irc.icq.com)


signature.pgp
Description: Digital signature

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

[Holger Levsen]

Hi,

On Sonntag, 1. März 2009, Carsten Hey wrote:
> And using stable and testing repositories together, e.g. during
> dist-upgrades, will be forbidden?  If not, it can't be avoided.

So what? It's not supported and the user has to fix manually. No big deal. 


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

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

[Holger Levsen]

Hi,

On Sonntag, 1. März 2009, Carsten Hey wrote:
> 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.

There is nothing _against_ current policy in this proposal. Also it's current 
policy (AIUI) that policy is modeled after current best practice and not the 
other way around.

> > > With mere "provides:" (a virtual package), you'd have a version of
> > > both exim4 and exim5 that provides default-mta.

In unstable, yes, but where is the problem? And for testing and stable this 
MUST be avoided :-)


regards,
Holger


signature.asc
Description: This is a digitally signed message part.

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

[Steve Langasek]

On Sun, Mar 01, 2009 at 04:55:23PM +0100, Andreas Metzler wrote:
> 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.

I think you could reasonably add the Provides: default-mta in your next
upload of exim4 without imposing any obligation on other packages.  I think
it should be straightforward to get this change through the policy process,
but if not you can just back it out again in a later upload with no harm
done.

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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Carsten Hey]

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

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

[Carsten Hey]

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

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

[Andreas Metzler]

On 2009-02-27 Steve Langasek  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@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-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Giacomo Catenazzi]

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

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

[Russ Allbery]

Steve Langasek  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 (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Steve Langasek]

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@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@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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Bill Allombert]

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 f...@example.com and b...@example.com: 
ssmtp allows
sendmail -oi f...@example.com,b...@example.com
  but not courrier-mta which want
sendmail -oi f...@example.com b...@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. 

Imagine a large red swirl here. 


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

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

[Adam Borowski]

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

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

[Giacomo A. Catenazzi]

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

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

[Holger Levsen]

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


signature.asc
Description: This is a digitally signed message part.

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

[Giacomo A. Catenazzi]

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

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

[Steve Langasek]

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@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 Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


-- 
To UNSUBSCRIBE, email to debian-policy-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org