Re: Bug#508644: mass bugfiling (against 8 packages) and/or new package default-mta
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
Reply to: