(I'm assigning this bug to apt because that package introduced the
relevant change, but I plan to mark it as affecting aptitude, whose
maintainer I'm X-Debbugs-Cc:-ing.)
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)
I'm attaching an archive containing output from aptitude
extract-cache-subset before and after an aptitude run demonstrating the
problem and a log of that run with Debug::pkgAutoRemove=yes (though I've
pruned /var/lib/apt/lists to save space); please let me know if you need
anything else.
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
Hi,
I have just stumbled over this as well.
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.
I did not run anything else than "aptitude safe-upgrade", IIRC.
Regards,
Sven
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. 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
Because it does not set it at all, it only ever uses the first two
parameters of MarkInstall, so FromUser is always true.
Anybody who wants to revive aptitude development should look into
modernizing these parts.
Cheers,
Sven
First off, I'd like to thank you (David) for responding promptly and Sven for providing a user perspective while I was asleep. David Kalnischkies <kalnischkies+debian@gmail.com> writes: [...] Thanks for the explanation. As my initial comment meant to indicate, I *don't* necessarily consider the bug to be in APT rather than aptitude, and merely assigned it to the former because it occurs only with newer versions thereof. If you honestly feel that the change was fully correct and merely revealed a previously latent bug in aptitude, please feel free to reassign this report. Sorry if that was unclear. BTW, like Sven, I've found aptitude safe-upgrade sufficient to reproduce the bug. Also, I belatedly realized that I forgot to attach the promised dumps; here they are now, FTR.
retitle 613775 MarkInstall calls with FromUser set to false
reassign 613775 aptitude 0.6.3-3.2
thanks
should discuss it before. So after that discussion i would strongly
recommend to switch aptitude in the future to use FromUser as needed.
In the meantime i have commited a quickfix which more or less restores
the old behavior in libapt-pkg - the changelog says:
+ * apt-pkg/depcache.cc:
+ - party revert fix in 0.8.11.2 which marked all packages as manual
+ installed if the FromUser bit is set in the MarkInstall call.
+ The default for this bit is true and aptitude depends on the old
+ behavior so the package is only marked as manual if its not marked
+ ("old" behavior) or if automatic installation is enabled - which
+ aptitude disables always (see also #613775)
The complete patch is attached (one line as always) and i guess Michael
will merge/upload it in a short while.
Best regards
David Kalnischkies
P.S.: I hope aptitude gets revived - it has A LOT of users who will miss it!
"There's life in the old dog yet." (through, the german saying sounds much
better in my ears: "Totgesagte leben länger")
David Kalnischkies <kalnischkies+debian@gmail.com> writes: That's fair. Great; thank you very much! I can confirm that it indeed accommodates the present version of aptitude. Likewise, though I can merely offer moral support, having barely enough time for my existing packages.
This section: 2.2.1. apt-get / apt-cache vs. aptitude … Note Although the aptitude command comes with rich features such as its enhanced package resolver, this complexity has caused (or may still causes) some regressions such as Bug #411123, Bug #514930, and Bug #570377. In case of doubt, please use the apt-get and apt-cache commands over the aptitude command. should be updated some time after the regressions have been resolved in stable. This is not only for those listed, but others such as #613775 (causes loss of auto-installed flag) and #672340 (serious multi-arch issue).
TL;DR: 1. clearing auto-installed is a side-effect of FromUser=true, not it's main purpose; 2. FromUser=true is mostly correct in aptitude; 3. since aptitude 0.6.4-1 we are calling MarkAuto after MarkInstall and the original problem of safe-upgrade clearing auto-installed on all packages is fixed [1]; 4. David's work-around in apt 0.8.11.5 can *probably* be removed, but I will need to investigate that further and follow up. Quoting David, who quotes Sven, who is quoting David: I have just completed a review of aptitude's use of MarkInstall, which is called in response to the user: a. requesting to install a package; b. requesting to upgrade a package; c. requesting to install a dependency, rather than a specific package satisfying that dependency; d. applying a solution from the problem resolver; e. requesting to upgrade all packages; and f. scheduling changes in one session and those changes being restored at the start of the next. a, b are directly from the user, ok. e is not directly from the user, and should be FromUser=false. I will mention the rest after a short diversion.. FromUser is also used in ::IsModeChangeOk() to determine whether a request should override a dpkg hold, etc.. It is a side-effect that this also causes MarkInstall to alter auto-installed in some cases. Maybe that side-effect is better suited to apt-get.cc (maybe not, for the reasons the change was introduced in the first place) but that is another discussion ;-) With that in mind, the rest of the list: d, f are not strictly direct, but the user has approved the changes and they should be applied, regardless of holds -- this makes FromUser=true *required* here. The problem resolver gives consideration to package holds already anyway. In both d and f, aptitude also tries to correctly keep track of auto-installed by itself, calling MarkAuto as needed. This is not perfect but appears to work most of the time at the moment. This leaves only c, when the user requests to satisfy a particular dependency but does not specify which package to use. At the moment we just install DepIterator::SmartTargetPkg(), but perhaps this should be more intelligent and give consideration to package holds. I think this being FromUser=true is ok for the time being. [Refer back to summary at top.] There is still some cases where auto-installed is cleared on some *but not all* packages involved in an action. This affects packages to be purged when the install run is aborted [2], and also some times when selecting “Keep at current version” in the problem resolver [3,4] (I suspect this is only when a package was going to be removed and keeping it cancels that). Regards [1] http://bugs.debian.org/622719 [2] http://bugs.debian.org/686573 [3] http://bugs.debian.org/638049 [4] http://bugs.debian.org/508428
There are two final cases I neglected to include: g. requesting to install a package set; and h. requesting to upgrade a package set. For now these also have FromUser=true, although as mentioned in [1] this may not always be desired (to respect holds, etc.). For installs at least MarkAuto must be used to make sure that packages which are installed are not left marked auto-installed as a side-effect of FromUser=false. Either that or continue using FromUser=true and use IsInstallOk on each package before deciding to call MarkInstall. This issue does also effect all uses of MarkDelete. [1] http://bugs.debian.org/452589