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