On ven., 2010-11-19 at 23:49 +0100, David Kalnischkies wrote: > 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… Hey, please don't put words in my mouth, I never said apt was too dumb. I said it looked to me like it was doing the wrong thing. And you don't have to take that personally either. > > > >> > 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). Hmh, I missed that. I thought Replaces was package wide for apt. > > 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… xfce4-settings replaces (functionnalities) xfce4-mcs-manager and xfce4-mcs-plugins, and ships files contained in those two packages. So Conflicts/Replaces is necessary, but indeed not enough. So I guess I'll have to version them, and add dummy packages back (yeah, NEW!). > > > >> 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?) In this case, I thought apt would use the Replaces: field for that. > 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. Good point. In that case it's a simple package upgrade, while usually the whole Xfce stack is installed. I've tried with the xfce4 metapackage and the upgrade correctly picks xfce4-settings and wants to remove MCS. So while the partial upgrade for only xfce4-session is a bit broken (well, if you ask for xfce4-session install it works too), in general it won't be a problem. Thanks for your help and your time. Regards, -- Yves-Alexis
Attachment:
signature.asc
Description: This is a digitally signed message part