Bug#282278: apt mixes essential flag from all sources
So many mails and i still don't get it…
(i am subscribed to apt bugs, so no need to cc me on everything btw…)
On Tue, Oct 18, 2011 at 12:18, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Vincent Lefevre wrote:
>> WARNING: The following packages were essential in the past and will
>> be removed. Though no longer essential, these packages may still be
>> needed by other (older) packages. Please look at the description of
>> these packages to see if it is safe to remove them.
>
> Sounds fine to me, with the caveat that it's not safe to assume that
> the release in which the package was essential is older.
That is the point, we never know in a reasonable sure way if the system
is on the 'oldstable' suite and has 'stable' in it, too, has a funky mix
of it or has completed (=whatever this means) upgraded to 'stable'.
If we go with the wheezy+20 perl-base essential drop example:
If we are on wheezy+19 yet in which perl-base is essential,
we need a really scary message displayed to discourage users to
shoot themselves in the foot, or are we in some funky mixture of it,
maybe because a dist-upgrade failed because of some packaging bug?
In that case what means 'other suite' here? It is just 'not the currently
installed suite for perl-base'? But this tells us nothing, perl-base is or
isn't upgraded yet, but this doesn't say anything about packages
implicitly depending on it, so the message should be still equally scary
as there are potential still packages thinking of perl-base as essential.
Last, we have "fully" upgraded to wheezy+20, perl-base isn't essential
any more for this release, but does all these obsolete packages know this?
And, why does the user have wheezy+19 archive still in the sources.list if
he doesn't get packages from there anymore?
Right, he either still gets packages from there making it a mixed system on
which perl-base needs to be installed as it is essential for exactly the
packages he gets from wheezy+19 sources OR the user wants to clean up his
system by removing now obsolete packages but doesn't start with the most
obvious cleanup step: Removing old sources…
In all but the last case changing the message is just plain wrong.
Beside, the message says:
"This should NOT be done unless you know exactly what you are doing!"
So there is the problem? Users who don't know what they remove?
Yes that is a problem and this message is specifically designed for those.
Users who know what they do? No, as the message explicitly say that you
can proceed if you know what you do.
APT can't determine automatically if something depends implicitely on
this previous/now/future essential package, so it treats all essentials
equally and off-loads the impossible task of taking implicit dependencies
explicitely into account to the user. That might be a problem for the user
as he has nobody to blame for if the system is broken after he hit enter,
but this isn't solveable by software…
So, can somebody please tell me a situation which can be detected without
doubt in which this message is wrong (= in which way can a confirmation
message be wrong?). Maybe i get an answer to it this time…
> Now, how to get the message in? Might be better to ask an APT expert
> that. If I were doing it, the logic would be vaguely like this
> (except probably I'd factor out a "spawn" function to decrease the
> boilerplate). Hopefully there's some appropriate APT API to look at
> the dpkg status database or the appropriate Packages file for the
> version of a package being removed.
Sure. A version has a list of VerFileIterators attached. Dropping this
into the RecordParser gets you access to the complete stanza as you
can see in apt-cache for various operations like show or search as
it needs to work with information we don't have in the binary cache
for various reasons. The essential flag is in this cache, but as
hinted above and said many times in this (ex-)bugcombilation recorded
as a package-attribute and not as a version-attribute for reasons
given (again) above.
Best regards
David Kalnischkies
P.S.: Vincent, Essentials can't just change their featureset.
If they are split up a metapackage with the old name remains,
so removing perl-extra would remove the old 'perl-base' metapackage
which APT complains about as being essential.
Thats also why a heuristic based on package content fails - perl-base
would be in this scenario such a package, so "easy" to remove, but
his dependencies hold the universe together, so to speak…
(Beside that APT just don't know the contents of a package)
Reply to: