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

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



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.


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?


Best regards

David Kalnischkies



Reply to: