Hi .*, 2010/4/28 Matt Taggart <tagg...@debian.org>: > 2) diffutils and dash are "Priority: required"/"Essential: yes" in > unstable, but weren't in lenny. Every time we talk about the "problem" outlined here it boils down to: Why the user still have the (old)stable repository in his sources?
If (s)he has no package left from this old archive it is as obsolete as the now obsolete transition packages (s)he want to remove. If (s)he still have packages from this old archive (s)he needs all essentials from this archive as otherwise the packages could be broken (they all depend implicitly on the essential packages). > 3) apt-get dist-upgrade thinks they should be pulled in (aptitude > dist-upgrade ignores them) Software can't easily tell if a package is left from the old archive, so apt-get chooses the "better safe than sorry"-approach. Other package manager (front-ends) choose a different approach. The most common annoyance with the apt-approach is a package rename, as can be seen in #544481 and friends -- can be easily fixed by the user with removing the obsolete source and/or by the project with a "package A replaces package B functional complete" semantic. (Replaces tell us only that a few files are replaced, Conflict+Provides+ Replaces doesn't work as we have a short timeframe in which no installed package provides the functionality, which is a no-go for essential packages) One counterexample is e.g.: Imagine perl-base will be dropped from the essential set: A user upgrades his perl stuff but keeps the rest in oldstable. Calling an orphanfinder application will quickly show perl-base as no longer needed so (s)he thinks it can be removed. After that all old packages which depend on the fact that the package was essential and therefore doesn't explicitly depend on it are now broken - which includes parts of dpkg btw. We can argue now that mixed systems aren't supported, but in the middle of a dist-upgrade from old-stable to stable the system is also a mixed system -- and, if we really would not support it, why does the user have different archives in his sources? > For apticron: can this be worked around or maybe just document ways the > user can prevent it from happening? By popular depend (or by us for debugging proposes) is a little cheat option implemented in apt (currently only in experimental) which can control the essential flag: pkgCacheGen::Essential=all|native|installed|none (you need to build the cache with this option!) I do not recommend to use nor do i will support the usage of this option (and because of that it is also not documented) but some people really thing it is important, so i don't want to stay in their way to break their system if they really want to do that, as i am bored by the whole discussion for a long while now - especially because this discussion generated far more mails than debian includes essential packages… I really thing we have better things to do than thinking about transition handling for ~30 packages… > For apt-get: > I suppose this could be seen as either a bug or feature, if the latter then > please leave open and tag wontfix (and make aptitude consistent). I don't like tag and severity ping pong and i am pretty sure this will happen as the frontline between bug and feature is quite large and everyone has its own opinion which is crystal clear and obviously right, e.g. [0]. aptitude is pretty independent from apt and can make decisions on his own. If aptitude would be consistent to apt in all his solutions you would not need one of the two… choose the tool which suites you best. > Regardless of the default, it might be nice to have a command-line switch > that controls the behavior so that things like apticron could specify what > they want. As said, such an option will exist in the future - but i don't think it is a good idea to be used by an other application as this will lead to the situation that apticron output differs from the "normal" output apt has and therefore confuses the user without (good) reason -- but i don't know how the output looks like and how the information is acquired, so i am maybe wrong. (beside that it needs more than the option to force a rebuild and after that need to rebuild the cache again without the option enabled for the user - and it overrides user configuration if the user has set the option already… It would be similar but less visible to using -t experimental in apticron) If the user don't want to see it (s)he can e.g. put the not installed package on hold and will be done with it… Best non-essential regards, David Kalnischkies [0] http://lists.debian.org/deity/2010/01/msg00088.html -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
