On Thu, Feb 17, 2011 at 05:31, Aaron M. Ucko <[email protected]> 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 ([email protected]): > * 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
