Package: aptitude
Version: 0.6.11-1+b1
Severity: normal
Hi.
There have been several bugs present over the years in which
aptitude (and perhaps also apt?? I only checked the following for aptitude,
it may easily apply to apt as well) forgot / cleaned manually set
auto-installed-flags on packages.
Some of these have been solved some years ago already, but some quite annoying
still persist.
The scenario is that an admin has set the auto-installed flag on packages,
which are not directly/indirectly depended upon/recommended/suggested by
any other installed package without the auto-installed flag set.
E.g. I have set the auto installed flag on
i A libefivar0
which in turn is pulled in by:
i A efibootmgr
which in turn is pulled in by:
i A grub-efi-amd64-bin
i A grub-efi-ia32-bin
which are not pulled in (depended/suggested/recommended) by any other
packages I'd have installed.
Having that situation may be non-standard but it may be quite handy,
e.g. to "remember" packages which I sooner or later want to remove again
(and they would show up when I do the remove unused packages)... or e.g.
to "mark" packages which in reallity "belong/relate" to other packages but
aren't recommended/suggest by them (yet).
And example for the later may be several doc-packages like cpio-toc, tar-doc
and so on, which clearly "belong" to cpio respectively tar (in the sense
it's typically rather useless for me to keep them, when I'd remove their
"base" packages, i.e. tar/cpio).
So that may be another situation in which people choose to manually mark
a package auto-installed, even though there is nothing else that actually
pulls it in (dependecy-wise).
Now unfortunately, there are several cases in which aptitude (again,
haven't checked apt) clears the auto-installed flag for such[0] packages.
The following is a rather fuzzy description of these situations:
- The manually auto-marked packages must be part of some package operation
(e.g. and upgrade or downgrade performed on them).
If then such operation is actually performed on these packages (optionally
with other packages), then there are two cases (AFAICT):
- when the operation succeeds
the auto-installed flags are properly kept
- when the operation fails (meaning that I e.g. abort it when
apt-listchanges and/or apt-listbugs ask me to)
the (some/all?) auto-installed flags are lost
- and I guess they're also lost, if the abort comes from "within" a package
e.g. when the maintainer scripts returns failure... but I'm not totally
sure about that case.
- The manually auto-marked packages must be part of some scheduled package
operation (e.g. and upgrade, downgrade, remove, purge scheduled on them)...
and then aptitude must be quit.
When it's then run again later, then often/sometimes/usually, [some/all of]
these manually auto-marked packages have their auto-installed flag cleared...
but the scheduled package operation (install/remove/etc.) is still remembered.
Generally, neither aptitude (nor apt) should IMHO ever change the auto-installed
flag except for probably those cases:
- the user manually clears/sets it
there could still be a command, which instructs it to clear the auto-installed
flags of all "dangling" packages (i.e. those which aren't directly/indirectly
"pulled" in by some non-auto-installed package)... but that shouldn't happen
automatically.
- the package is purged (then it should be cleared)... not sure about what's
best
in the remove-but-not-purged case, perhaps it should stay?
- the package is actually installed automatically as part of some other package
installation (in which case the flag is of course to be set automatically).
Maybe there are other cases which I haven't thought of right now,... but at
least
it should be fixed that the flag isn't cleared in the situations described
above.
Thanks,
Chris.
[0] Interestingly, it seems (don't remember exactly all cases, that it
doesn't necessarily to this clearing for all the involved packages.
For example, I believe to remember cases, where e.g. both
libefivar0 and efibootmgr were involed in package operations,
but the flag was only cleared on libefivar0.
But as said, I don't remember every single ocurrance of this issue,
so my mind may just play tricks on me.
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
