Bug#613775: aptitude upgrades lose extended state (automatic status)
On Thu, Feb 17, 2011 at 11:10, Sven Joachim <svenjoac@gmx.de> wrote:
> On 2011-02-17 10:47 +0100, David Kalnischkies wrote:
>> On Thu, Feb 17, 2011 at 05:31, Aaron M. Ucko <ucko@debian.org> wrote:
>>> I've found that with recent versions of apt installed, telling aptitude
>>> that I'd like to upgrade any packages results in losing extended state
>>> for all upgradable packages, which it proceeds to consider manually
>>> installed. AFAICT (with help from bzr's unofficial bisect plugin),
>>> revision 2073.1.3 is
>>> at fault:
>>>
>>> On revision 2073.1.3 (kalnischkies@gmail.com-20110211164750-u0982elp6wnjh639):
>>> * apt-pkg/depcache.cc:
>>> - mark a package which was requested to be installed on commandline
>>> always as manual regardless if it is already marked or not as the
>>> marker could be lost later by the removal of rdepends (Closes: #612557)
>>
>> In that case it would be an aptitude bug as it would call MarkInstall
>> with FromUser == true for requests which are not directly from the user
>> and should therefore not be marked as manual.
>>
>> As the changelog entry tries to describe in a request like
>> apt-get install A
>> A is now always marked as manual installed.
>>
>> Previously, it was checked if A is already marked (= not garbage) and only
>> if not it was marked as manual. Thats faulty every time this request results
>> in the removal of B which was the package responsible for marking A.
>> The package A would be garbage then - this results normally in the funny
>> output that A is considered garbage and can be autoremoved and at the same
>> time its explicitly upgraded by the user, but if you activate automatic
>> autoremove the package A is removed in the request to install/upgrade it!
>> (Isn't the last one aptitudes default behavior?)
>>
>> The rationality is simple that if the user cared enough to request install
>> of a new version of this package (s)he would be depressed so see it marked
>> for removal in the next autoremove run. Especially as the same command
>> if no newer version is installable marks the package as manual installed, too.
>
> This may make sense for apt-get, but I would like to be able to upgrade
> some selected packages _without_ changing their manual/automatic state.
> Especially in interactive situations (like aptitude's TUI/GUI or in
> synaptic) this seems better. Especially since there are dedicated
> commands for changing the manual/auto status.
Which is fine, the software just shouldn't request to alter the autobit if
it doesn't want it to be changed - the FromUser bit is exactly responsible
for that and nothing else, so why setting it if you don't want it?
Just to be clear, it was possible that the autobit was changed already by
the "old" behavior which doesn't make sense in your usecase as well.
I discussed that with Michael quiet a bit and we don't see a reason for
this "random" condition: Flipping the autobit only if the package is not
marked changes depending on what requests are served before or after
in the same run - so the behavior depends on the order in which the
requests are executed which is always bad.
>> So could you please describe more detailed why do you consider it a bug
>> in APT rather than in aptitude? Exact commands you use for example?
>
> I did not run anything else than "aptitude safe-upgrade", IIRC.
apt-get (dist-)upgrade does all MarkInstall requests in this situation
with FromUser == false as no installation was requested explicitly.
The question is now why aptitude sets the FromUser bit here to true…
Best regards
David Kalnischkies
Reply to: