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