[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Full install/removal/upgrade test results available

On ven., 2010-11-19 at 19:23 +0100, David Kalnischkies wrote:

> So, go and start reading. Debian has a lot of dependencies and you have a
> lot of possibilities because of that.
> You can't use them if you don't know them.
> And, more important, you can't blame APT for being stupid if you don't
> know what you talk about yourself.

Well, I thought that Recommends: and Depends: were different things,
which looks to me like a fair assumption. It seems I'm wrong.

Oh, and I don't really like your tone, and I'm not usually offended by

> > By the way, adding a Breaks: xfce4-mcs-manager in xfce4-settings doesn't
> > work either, apt will still prefer to hold xfce4-session and keep
> > xfce4-mcs-*.
> You have way more information than APT - for example:
> Is it communicated that xfce4-mcs-manager and xfce4-mcs-plugin are
> now obsolete? No. All which is said is that the new xfce4-session doesn't
> work with them (it breaks them).

No, xfce4-session depends on xfce4-settings. And xfce4-settings
*replaces* xfce4-mcs-*.

>  So, for APT its clear that we loose two
> packages just to get another one upgraded… that doesn't feel right.

Even with the Replaces: bit?

> Before you ask, no, debian has no way to say: "this package is
> obsolete -
> its fine that it will be removed as other packages take care of its
> tasks."
> The closest thing to that is §7.6.2, but i doubt that this is really
> such
> a drop-in replacement in your case.
> (and that doesn't say anything about an upgrade path, too)

Well, it is a replacement, and I don't see such a thing as “drop-in”
replacement (and this is not a virtual package).

> So, to solve your problem, you have more or less only one option:
> Do not try to clean up behind you, let the package managers do it
> (with autoremove or deborphan or whatever). Trying it yourself only
> complicates stuff -- and adding Breaks for this kind of stuff is even
> against the policy if you want to read it that way: §7.4

Except that in my case, I'm more in the $7.6. I'm not adding
Conflicts/Replaces just because I'd like to force people to get rid of
xfce4-mcs-*, it's just that it xfce4-settings needs it. They both ship
common files (along with xfce4-mcs-plugins) and xfce4-settings replaces
the functionality provided by xfce4-mcs-manager.

> > Neither Breaks nor Conflicts should be used unless two packages
> > cannot be installed at the same time or installing them both causes
> > one of them to be broken or unusable.

Which is the case here, and why the fields were added in the first
> Or in short: either make empty dummy packages out of them or
> just leave them alone.

Which would then need to Depends on xfce4-settings in order to provide
the same set of functionality, adding complexity to the dependencies.


Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: