Christophe Lohr wrote:
> Severity: wishlist
Pardon me butting in on your wishlist; I'm just a random bystander,
but you reminded me of an unsubmitted wishlist item of my own that
might in fact be a better match for what you're after.
> Hi,
> aptitude can mark a package as "manual installed" or
> "automatically installed". Symmetrically, I suggest to introduce a
> way to mark a package as being "manually removed" or
> "automatically removed".
>
> Similarly, aptitude should avoid to automatically reconsider a
> "manual" decision.
>
> For example, if a packet is marked as having been "manually
> removed", aptitude should not try to install it again on the pretext
> that another package recommends or suggests it.
This could easily lead to trouble in day-to-day use. Imagine:
* I install package foo. It depends on either bar or baz, so I let
it pull in the default, bar.
* When I decide to try foo with baz, I manually remove bar (since
that's the easiest way to get foo to switch to using baz);
aptitude silently "blacklists" it.
* Later I discover the package quux, and ask aptitude to install
it. It would also like to pull in bar, but doesn't.
* Unfortunately, quux needs bar - it's just that in principle it
can be configured to use a remote bar-server, so it only has
a Recommends instead of a Depends.
* Thus I end up with an inoperable quux install.
Most of the time when I uninstall a package, I'm not ruling out the
possibility I might someday want it back. A package I genuinely
want to tell to get out and stay out is an exceptional case; and it
seems to me that what I'm after there is something more like purging
it and then putting it on hold. At present, "hold" means "keep
version X.Y-Z installed", and can only be applied when the package
is in fact installed; maybe it could be generalised to let me "hold
off" unwanted packages ("keep version NULL installed").
Thus for instance if I wanted to install individual GNOME-compatible
apps without them automatically inviting all their friends along
with them I would be able to put gconf2 on hold-off to break the
dependency chain. Notice that doing it this way means I never need
to have had it installed in the first place. It would also make
sense to let it apply to virtual packages.
Another way of getting there would be to extend forbid-version so it
interprets "aptitude forbid-version gconf2=*" as "forbid all
versions". Oh, except that forbid-version doesn't seem to stop
packages being pulled in by dependencies.
Yet another approach that's already possible (with some effort) is
to use equivs to create a dummy dependency package that declares a
"Conflicts: gconf2".
--
JBR
PS: and a pony!
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
