Eugene V. Lyubimkin wrote:
> I see three ways to "resolve" this bug:
>
> 0) Reaffirm that unmarkauto command should be used whenever
> user wants to say "this was automatically installed initially, but now I
> want to keep it". Close the bug as not a bug.
>
> 1) Agree that some users want less aggressive auto-removal, turn this
> bug into a wishlist one to provide an option to turn off "that change in
> Cupt 2.4.0".
>
> 2) Further discussion. For example, more arguments why new behavior may
> be unnacceptable as a default, or implementing more fine-grained setup
> to specify user-level dependencies like
>
> cupt::resolver::user-dependencies { "xserver-xorg: Depends:
> xserver-xorg-video-i128, xserver-xorg-video-nouveau" };
>
> , or other suggestions.
Quick reactions:
Of course this is no democracy :), but if forced I'd vote 2 0 1.
I can imagine myself using a "weakly non-auto" state[*] signifying
that this package should be kept as long as it can be used to satisfy
a dependency. If I were cupt maintainer, I would probably turn this
report into a wishlist item for storing a list of packages to
distinguish which are the automatically installed packages the user
does not care about, and which the user hand-picked and does not want
to see removed for frivolous reasons.
The weakly non-auto category might even deserve to be called "marked
auto" for compatibility with apt and aptitude[**]. Whatever it is
called, packages that are automatically installed to satisfy
dependencies should not be automatically placed in this category,
since otherwise a sequence like
cupt install gnome
cupt purge gnome
or
cupt install xserver-xorg-video-all
cupt purge xserver-xorg-video-all
would leave behind a bunch of cruft in packages that happen to be one
of the alternatives to satisfy a dependency in another package.
Thanks for your thoughtfulness, and hope that helps.
Jonathan
[*] Sorry, I am awful at naming things.
[**] I haven't checked: are packages marked auto documented to behave
that way?
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
