| Summary: | package move should not be abused for completely unrelated packages (beryl -> compiz-fusion) | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Jakub Moc (RETIRED) <jakub> |
| Component: | Eclasses | Assignee: | Hanno Böck <hanno> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | cedric.godin, notify, qa |
| Priority: | Highest | ||
| Version: | 2007.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Jakub Moc (RETIRED)
2007-11-06 09:57:37 UTC
[ebuild N ] x11-libs/compiz-bcop-0.6.0 69 kB [ebuild UD] x11-wm/compiz-0.6.2-r1 [9999] USE="dbus%* -debug% -gnome% -kde% svg%*" 1,743 kB [ebuild UD] x11-plugins/compiz-fusion-plugins-main-0.6.0 [9999] USE="(-dbus%*) jpeg%* (-vidcap%*)" 767 kB [ebuild UD] x11-libs/libcompizconfig-0.6.0 [9999] 314 kB [ebuild N ] dev-python/compizconfig-python-0.6.0.1 250 kB [ebuild N ] x11-plugins/compiz-fusion-plugins-extra-0.6.0 2,240 kB [ebuild UD] x11-apps/ccsm-0.6.0 [9999] 407 kB [ebuild UD] x11-wm/compiz-fusion-0.6.0 [9999] USE="-gnome -kde" 0 kB [ebuild N ] x11-wm/beryl-core-9999 0 kB [1] [ebuild N ] x11-plugins/beryl-plugins-9999 USE="dbus vidcap" 0 kB [1] You might also want to follow the regular procedures for removing ebuilds from the tree. All the beryl stuff just vanished overnight. :( There really needs to be new deps and blocks like there normally are. When you just remove a package you break everything: raphael ~ # emerge -auDN world These are the packages that would be merged, in order: Calculating world dependencies | emerge: there are no ebuilds to satisfy "~x11-wm/beryl-core-0.2.1". (dependency required by "x11-wm/heliodor-0.2.1" [installed]) This is ignoring the fact that heliodor and emerald have been broken for months now anyway (see Bug 189374). The only decorator that works on my system is Aquamarine/KDE. hanno - hello? Like, this is an urgent issue, not something to sit here for days/weeks... This commit sets people's systems to undefined state. Hi, ok, some statement from me. First of all, this was a security issue (bug #196878) and with security issues I always think it should go fast. Maybe I was too fast in this case, anyway, I've asked tsunam (he added the beryl-packages to gentoo) what to do and he agreed to update beryl to it's corresponding cf-packages. Second, the subject of this bug is wrong, beryl is dead upstream and cf is it's successor. Most packages that were beryl-* are now some part of cf. So they're not "unrelated", they're mainly just renamed versions. And that's what update is for, or am I seeing something wrong? What I didn't think of was that this would make it impossible to use external beryl-ebuilds. But anyway, what would be the correct solution for something like that? Now what remains is what to do now: Shall I remove the update-lines again, thus making it possible to still use external beryl-sources? Or will this cause even more breakage? (In reply to comment #5) > First of all, this was a security issue (bug #196878) and with security issues > I always think it should go fast. Maybe I was too fast in this case, anyway, > I've asked tsunam (he added the beryl-packages to gentoo) what to do and he > agreed to update beryl to it's corresponding cf-packages. See, this is just wrong. Imagine something depends on compiz; now you've renamed beryl-core to compiz; will that compile? Sure it won't, and you don't have any way to determine what the user has really installed. > Second, the subject of this bug is wrong, beryl is dead upstream and cf is it's > successor. Might well be dead, don't force-migrate users like this. I've already explained above that there are legitimate reason why people do not want to use compiz. > Most packages that were beryl-* are now some part of cf. So they're > not "unrelated", they're mainly just renamed versions. And that's what update > is for, or am I seeing something wrong? See above. And no, using compiz core and recycling a bunch of beryl ideas and transferring them to compiz-fusion plugins doesn't make that a 'renamed version', it's a completely different thing. It's kinda like you'd pkgmove KDE to Gnome because both are desktop environments. > Now what remains is what to do now: Shall I remove the update-lines again, thus > making it possible to still use external beryl-sources? Or will this cause even > more breakage? Well, it's already broken in a way that cannot be automatically repaired. Restoring the ebuilds you've nuked overnight, reverting the commit and sticking a message to beryl package.mask on how to manually repair the damage it probably best we can do here. Plus revbumping all compiz stuff and setting the dependencies so that they specifically depend on the revbumped revisions so that we get deterministic dependencies there. (In reply to comment #5) > Now what remains is what to do now: Shall I remove the update-lines again, thus > making it possible to still use external beryl-sources? Or will this cause even > more breakage? Remember that you're only responsible for the state of the tree and its own internal consistency. If something in the tree breaks an overlay, the overlay should be fixed/changed. It isn't our job to go around keeping things in the tree just because it might otherwise adversely affect some random user using some random overlay, even if said user is a developer. Put simply, the tree trumps all. All that being said, with my limited knowledge of the whole beryl/compiz-fusion thing, I can't comment much on what you should actually do here other than what I stated above. (In reply to comment #7) > Remember that you're only responsible for the state of the tree and its own > internal consistency. If something in the tree breaks an overlay, the overlay > should be fixed/changed. It isn't our job to go around keeping things in the > tree just because it might otherwise adversely affect some random user using > some random overlay, even if said user is a developer. Put simply, the tree > trumps all. > > All that being said, with my limited knowledge of the whole beryl/compiz-fusion > thing, I can't comment much on what you should actually do here other than what > I stated above. > In complete agreement. I also dont' know much about beryl and compiz-fusion, which is why I sent something to g-dev@ to try and find out if this is the correct thing to do in these situations. (In reply to comment #7) > Remember that you're only responsible for the state of the tree and its own > internal consistency. If something in the tree breaks an overlay, the overlay > should be fixed/changed. Sure; anyway as noted above, this affects gentoo-x86 tree as well, all those beryl ebuilds have been there as well. I'm not using a single overlay and this is still causing breaking in the default tree. Beryl should have been masked and compiz-fusion should be set to provide dependencies for apps like aquamarine and heliodor. Those apps should have had their dependencies changed to compiz-fusion and people should have seen blocks like with any normal upgrade. If compiz-fusion provides everything within aquamarine and heliodor (or obsoletes it), those packages should now block compiz-fusion. The current result provides no information to the user for the correct upgrade path. Even look at this bug I'm still confused as what the correct update path should be. I am also stupidly confused on the state of beryl. On the main website for beryl it says "Beryl and Compiz (at least the extra plugins division of compiz) have merged. Please all welcome Compiz Fusion!" But if you go to compiz-fusion's site and look at http://wiki.compiz-fusion.org/CompizFusionVsCompiz It says compiz-fusion isn't a replacement for compiz/beryl. Confusing? Yep. What is the correct upgrade path for those of us who do not use overlays? I'd be willing to put together a guide on the wiki or create a docbook if we could make that clear. Now I've reverted the update-lines and masked the remaining beryl-related packages aquamarine and heliodor. This should make the way free for people that want to use beryl with external overlays. compiz and compiz-fusion-related packages already dep on minimum versions of their libraries, so there shouldn't be any deps satisfied by moved beryl packages. I think there's nothing more I can do for now. |