Re: Full install/removal/upgrade test results available
On Fri, Nov 19, 2010 at 22:10, Yves-Alexis Perez <corsac@debian.org> wrote:
> 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
> rudeness.
And i am usually not offended by someone blaming APT to be too dumb.
APT is all about dependency resolution, so saying you are not to deep
into it, but blaming APT to be wrong isn't the best tone either.
Draw i would say…
>> > 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?
Great, just that Replaces: only says that some files will be replaced,
not the complete package… (so its mostly only used by dpkg).
APT currently Replaces: manpages-pl as it ships its own manpage
translation now. Should APT assume now while upgrading itself
that it is a complete replacement for manpages-pl ?
My example with apt and java is similar: They will declare
Replaces and Breaks as they conflict on filename usage and
installing the one breaks the other… java is still no valid upgrade
path for apt nor vise versa.
>> 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)
They ship common files => Replaces
Or is xfce4-mcs-plugins broken now that you replaces some of its files?
(or better as footnote 46 suggests: Does it hurt if the files are gone?)
Then it really also Breaks:, but you also give the indication that
something in xfce4-mcs-plugins is left which can be broken and
therefore functionality is lost by removing it… (or allowing the other
package to replace files of it in the first place).
So you might want to provide a new xfce4-mcs-plugins without
these files (by depending on them) which still provides this functionality
(or nothing as a dummy package).
> and xfce4-settings replaces
> the functionality provided by xfce4-mcs-manager.
dummy xfce4-mcs-manager depending on xfce4-settings if it is
a package rename. If its not, but they do not conflict just leave
xfce4-mcs-manager alone. If they conflict as they use the same files,
its the same as with the other package…
>> 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.
In general positive dependencies are easier to satisfy than negative
as it is easier to install another package than to remove an installed.
If we install a new package we have a relatively low probability that a
negative dependency will effect it later. If we remove a package we can be
nearly sure that another package depends on it and is now broken.
(why would it be installed otherwise?)
Also, a user normally doesn't complain too much if new functionality
is added, but heavily if some functionality is gone without good reason…
And the "good reason" is why APT doesn't remove the package on the
breaks - the 'Considering' line in the output shows the scores the packages
have. 0 vs 0 isn't a strong thing. If more packages would depend on
one of the packages the decision will follow the highest scoring package.
To go back to the apt and java example: On most systems, far more
packages depend on apt, so if APT would need to choose, between
the two it would choose apt - but if the system is full of java packages
it might choose to prefer java instead -- depending on how broken the
system is after deciding for one of the sides.
And as the system is more broken if xfce4-session is upgraded, why
should APT walk this way…
Best regards
David Kalnischkies
Reply to: