Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 12:59, Yves-Alexis Perez <corsac@debian.org> wrote:
> On 19/11/2010 12:29, David Kalnischkies wrote:
>> xfce4-mcs-manager recommends it.
>> As APT has no indication that this package can go away it does the
>> only right thing (TM): Chooses to keep xfce4-mcs-plugins as otherwise
>> the user will lose functionality…
>> (recommends are defined as installed on all, expect "unusual" systems,
>> so their value is very close to a depends for APT)
>
> Except it's not. System would be perfectly usable with xfce4-mcs-plugin
> and without xfce4-mcs-manager (it wouldn't make much sense, but still).
> Preferring to ignore a Breaks: in order to keep a Recommends: satisfied
> looks to me like the wrong thing to do, though I'm not fluent enough in
> dependencies to be sure.
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.
Oh, and in the end, i am not a D{D,M}, so you shouldn't trust me and
what i say about a policy as i don't upload packages to the archive
which needs to comply to that policy…
> 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). So, for APT its clear that we loose two
packages just to get another one upgraded… that doesn't feel right.
Just imagine dpkg gets a new console interface and therefore isn't
compatible with apt/aptitude anymore - should APT really decide to
remove apt, aptitude and friends just to upgrade dpkg? No. Better wait
for apt, aptitude and friends to be upgraded to work again with dpkg
and retreat from upgrading dpkg now (in that case the breaks would be
versioned, but still).
We have cases in which packages in extra break each other - this
doesn't mean they obsolete each other - it doesn't even say that they
do the same nor even something similar, it just says that they doesn't
work together on the same system (unversioned as the breaks here).
If apt would provide a /usr/bin/apt it could break java for example (and v.v.)
as this provides /usr/bin/apt too - it should be clear that apt and java
have nothing in common expect that they use the same name for
an executable… (yes, thats completely made up, in reality this binary
is already an alternative - but even then it would feel strange to provide
an alternative with apt for javas annotation processing tool…)
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)
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
> 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. Having similar functionality or
> performing the same tasks as another package is not sufficient
> reason to declare Breaks or Conflicts with that package.
Or in short: either make empty dummy packages out of them or
just leave them alone.
Best regards
David Kalnischkies
P.S.: The first option will be revisited and properly enhanced at the time
of wheezy (aka "disappearing packages") but let us talk about that later…
Reply to: