Hi James and Jonathan,

[ Jonathan, I don't know do you want explicit CCs or not, kept it for
now ]

On 2012-02-06 22:01, James McCoy wrote:
> On Mon, Feb 06, 2012 at 08:37:47PM -0600, Jonathan Nieder wrote:
> > > Since upgrading to 2.4.0, various packages are suddenly showing up as
> > > "to be removed".  As far as I can tell, this is only happening when
> > > those packages are satisfying an ORed relationship.

Yes, this was an intentional change in the 2.4.0, from the changelog:

| Removing automatically installed packages: if several automatically
| installed packages satisfy the relation, leave only first of them.

The rationale of the change is:

On a typical system there are quite a many packages installed, and many
Depends/Recommends with alternatives. In many (but not all) cases users
don't care about what alternative is chosen deeply in the tree of
dependencies. Now, when packages are getting installed and removed,
installed and removed, some alternatives to already satisfied
Depends/Recommends are accidentally installed as needed for other
packages but are never (automatically) deleted as they satisfy some
relation for existing packages. In a nutshell:

-8<-
Package: M
Depends: X | Y | Z

Package: N
Depends: Z

Step 1: M is installed, X is installed.
Step 2: install N, Z is now installed too.
Step 3: remove N

Prior to Cupt 2.4.0 (and I guess in some other package managers), Z
would never get autoremoved. Still I believe that auto-removal of Z is a
right thing to do, at least by default.

> > > The following packages will be removed:
> > >
> > > [...] xserver-xorg-video-i128(a) xserver-xorg-video-intel(a) 
> > > xserver-xorg-video-nouveau(a) xserver-xorg-video-vesa(a)
> > [...]
[...]
> > > All of the installed xserver-xorg-video-* packages Provide
> > > xorg-driver-video and xserver-xorg-video-all isn't installed.
> > 
> > I don't see a bug here.  You only need one video DDX package to satisfy
> > the dependency by xserver-xorg, so presumably you will want to do
> > 
> >     cupt unmarkauto xserver-xorg-video-i128
> >     cupt unmarkauto xserver-xorg-video-nouveau
> >     ... etc ...
> > 
> > to indicate that these packages are not installed just to satisfy a
> > dependency but because you want them.

Indeed, that's how I see the situation.

> That's an interesting read on the problem.  That does look like it could
> be the explanation since in both cases one package satisfying the ORed
> relationship is being kept (cups-client and xserver-xorg-video-fbdev).

Exactly.

[...]
> Maybe my expectations are just biased based on the other package
> management tools I've used in Debian.  I've understood the "auto"
> flag to mean the package is satisfying a strong relationship and can be
> removed when the package(s) declaring those relationships have been
> removed.  I can see how, from a package management tool perspective, it
> makes things easier to take the stricter stance that I'm now seeing in
> cupt, though.

I saw this change as positive for users who want to see as less
packages in the system installed as possible. Especially for those who
tend to to change a set of installed packages regularly.


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.

-- 
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++/Perl developer, Debian Developer



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to