[Aptitude-devel] Bug#548505: aptitude reports incorrectly essential packages

[Manuel A. Fernandez Montecelo]

Control: tags -1 + pending


Hi all,

2009-10-07 15:51 Daniel Burrows:
>On Tue, Oct 06, 2009 at 06:32:22PM +0200, Vincenzo Tibullo <enzotib at gmail.com> was heard to say:
>> 2009/10/5 Daniel Burrows <dburrows at debian.org>:
>> > Internally, aptitude maps "~E" to testing the flags "essential" or
>> >"important".  
>>
>> I think this is not what user expect.
>
>  True.  "important" is not a concept that's documented anywhere.  The
>only hesitation I have is that it's a change from aptitude's historical
>behavior, and I don't want to modify that precipitously.  However, I'll
>probably do it eventually, since this is a very small corner case.

I changed this now, so ~E doesn't match those which come from apt with
flag "Important" (because of what D.Burrows says above, and also see
also at bottom of this message).


>> >This is also what it does when testing whether to warn
>> >the user about packages they're removing.
>>
>> >apt always turns on the
>> >"important" flag for the package named "apt", regardless of whether
>> >Essential is set to true for it.
>>
>> This is not clear to me: what do you mean by "apt always turns on the
>> 'important' flag for the package named 'apt'"?
>
>  When apt is setting up its internal structures, it turns the Essential
>flag on for packages with "Essential: yes", and it turns the Important
>flag on for packages with "Important: yes" (of which there are none).
>It also turns it on for packages named "apt", of which there is exactly
>one (obviously :) ).

... and now, Important continues to be zero and apt declares itself
Essential and Important internally, depending on some conditions, so the
output is exactly the same as before.

So in a way, this aspect of the bug report is not addressed with the
current fix.

However, if we disregard these flags and go and parse the raw package
records...  seems a bit heavy-handed, going out of our way and probably
inefficient, so I don't know if it's better to do that.

The options are:

a) Do the heavy-handed method anyway, even if expensive

b) Warn in the docs about this specific apt "implementation detail"

c) Mark this bug as +wontfix

d) Ask apt developers to not do that internally

e) Keep this fix checking only for Essential, and do nothing else
   regarding this problem

f) Something else


2011-10-16 03:16 Josh Triplett:
>Package: aptitude
>Version: 0.6.4-1
>Followup-For: Bug #548505
>
>I just hit this today myself, and it resulted in the filing of bug
>645451.  Any status on this bug?

So, about one of your messages in that bug report -- it is apt marking
itself as essential, not aptitude treating apt in any special way.

The reason why "cupt/aptitude/... show apt | grep Essential" does not
show it as essential it is because it shows a more-or-less raw record,
where "Essential: yes" is not present.

If the Important flag is not used by any package perhaps it should be
removed from apt, and the reason why apt has "flag Essential" in both
apt (internally) and aptitude is up to apt.  I don't know if apt or
other front-ends (cupt, synaptic, python-apt...) use these flags for
something else.

aptitude does now what Julian recommends in the last message of the
report:

  "aptitude should be changed to ignore the Important flag when
  searching for essential packages."


Cheers.
-- 
Manuel A. Fernandez Montecelo <manuel.montezelo at gmail.com>