Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 198248 - package move should not be abused for completely unrelated packages (beryl -> compiz-fusion)
Summary: package move should not be abused for completely unrelated packages (beryl ->...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: Highest major (vote)
Assignee: Hanno Boeck
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-11-06 09:57 UTC by Jakub Moc (RETIRED)
Modified: 2007-11-07 17:09 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Moc (RETIRED) gentoo-dev 2007-11-06 09:57:37 UTC
Hanno, this commit [1] made using my beryl overlay completely impossible and produced a real mess on my system, with various downgrades and pretenting that I have packages installed that I never have, and never intended to. 

This is a real PITA, I do NOT want to use compiz-fusion. You know, there are distros out there that still keep beryl in their repositories, because there are genuine issues w/ compiz-fusion (be it slowness, bugs or whatever else). The above commit made it impossible for people to use the old ebuilds we provided if they wish so, and made it impossible for them to use their own beryl overlays.

Please do NOT abuse the package move feature for such things and revert this.

[1] http://sources.gentoo.org/viewcvs.py/gentoo-x86/profiles/updates/4Q-2007?r1=1.9&r2=1.10
Comment 1 Jakub Moc (RETIRED) gentoo-dev 2007-11-06 09:58:21 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]
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2007-11-06 10:12:48 UTC
You might also want to follow the regular procedures for removing ebuilds from the tree. All the beryl stuff just vanished overnight. :(
Comment 3 Sumit Khanna 2007-11-06 14:33:02 UTC
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.
Comment 4 Jakub Moc (RETIRED) gentoo-dev 2007-11-06 22:21:11 UTC
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.

Comment 5 Hanno Boeck gentoo-dev 2007-11-06 22:46:43 UTC
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?
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2007-11-06 22:59:50 UTC
(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.
Comment 7 Chris Gianelloni (RETIRED) gentoo-dev 2007-11-07 01:57:37 UTC
(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.
Comment 8 Mark Loeser (RETIRED) gentoo-dev 2007-11-07 02:08:05 UTC
(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.
Comment 9 Jakub Moc (RETIRED) gentoo-dev 2007-11-07 07:00:09 UTC
(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.
Comment 10 Sumit Khanna 2007-11-07 14:54:16 UTC
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. 
Comment 11 Hanno Boeck gentoo-dev 2007-11-07 17:09:11 UTC
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.