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

Bug#613775: aptitude upgrades lose extended state (automatic status)


I have just stumbled over this as well.

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.

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


Reply to: