[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#544481: apticron: apt-get dist-upgrade pulling required packages from unstable

David Kalnischkies <kalnischkies+debian@gmail.com> writes:

> Hi .*,
> 2010/4/28 Matt Taggart <taggart@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).

You have the problem backward in this case.

The user has stable with a few select packages from unstable. Unstable
is pinned down so the default remains stable. In UNSTABLE diffutils and
dash are essential but in stable they are not and they are not

But you are also right. If even one package from unstable is installed
then everything essential from unstable must be installed because that
one package may depend on it being there.

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

If by "old" you mean lesser pinned then yes.

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

And most cases aren't about a transition but about maintaining a mixed setup.
And in a mixed setup the essential debs from all releases must be


Reply to: