This is an improvement that will allow for automatic rebuilds of chromium when v8 is upgraded to a different SONAME. I've been playing with it in my overlay a bit. I'll document any issues I run into here.
(In reply to comment #0) > This is an improvement that will allow for automatic rebuilds of chromium > when v8 is upgraded to a different SONAME. > > I've been playing with it in my overlay a bit. I'll document any issues I > run into here. Sounds great! I took a look at the overlay and the implementation also looks good to me. Some comments: Did you hit issues with python.eclass? If so, it may be better to also adapt it to EAPI 5 rather than adding hacks, at least in the main tree. When landing this in the main tree, we should also update all other reverse dependencies of v8. Before landing in the main tree we should make sure stable portage supports EAPI 5 in time. chromium has a 6-weeks release cycle, and a fast track stabilization of portage when we need a security stabilization of chromium is not the best idea. The slot-operator deps are going to be extremely helpful for security updates of v8. For now it was difficult to write good update instructions for v8, because all reverse deps have to be recompiled to use updated v8, but we preserve old libs, so regular revdep-rebuild doesn't catch the need to rebuild. Slot-operator deps solve this very cleanly. Thanks for working on this, it's cool to see a working implementation! You may want to announce it on your blog so more people test it.
(In reply to comment #1) > Did you hit issues with python.eclass? If so, it may be better to also adapt > it to EAPI 5 rather than adding hacks, at least in the main tree. > Yeah, python.eclass called die with EAPI 5. I bumped that in the tree yesterday, so I'll put it back in the chromium ebuilds.
(In reply to comment #1) > Before landing in the main tree we should make sure stable portage supports > EAPI 5 in time. chromium has a 6-weeks release cycle, and a fast track > stabilization of portage when we need a security stabilization of chromium > is not the best idea. In the back of my head, I'm thinking chromium-24 would be a good target. If portage is not stable by the time that hits the beta channel, we can back it out.
Pacho brought up a good point as a response to my blog. If we remove the preserve_old_lib calls, chromium (and other reverse deps) will be broken until the automatic rebuild completes, unless the user sets FEATURES=preserve-libs.
(In reply to comment #4) > Pacho brought up a good point as a response to my blog. If we remove the > preserve_old_lib calls, chromium (and other reverse deps) will be broken > until the automatic rebuild completes, unless the user sets > FEATURES=preserve-libs. That's a nice result of posting, thanks! I think this is beyond the scope of v8 maintainership though. The same point can be applied to any other package that switches to slot-operator deps. By the way, a possibly more interesting question is what to do with v8-9999.
(In reply to comment #5) > By the way, a possibly more interesting question is what to do with v8-9999. I can't see a way to populate a useful slot/subslot for that. SLOT is part of the ebuild metadata, so it has to be invariant. preserve-libs should still work here -- just the rebuilds won't be automatic.
Stable portage supports this now. I will implement the v8 subslot and slot-operator deps in the tree later this week with a revbump on the beta channel ebuilds (v8-3.14.5, chromium-24). My plan for v8-9999 is to just leave the SLOT as-is without a subslot.
25 Nov 2012; Mike Gilbert <floppym@gentoo.org> v8-3.14.5.1-r1.ebuild, v8-3.15.1.2-r1.ebuild, v8-9999.ebuild: Fix python dependency and merge changes into live ebuild. *v8-3.14.5.1-r1 (25 Nov 2012) *v8-3.15.1.2-r1 (25 Nov 2012) 25 Nov 2012; Mike Gilbert <floppym@gentoo.org> +v8-3.14.5.1-r1.ebuild, +v8-3.15.1.2-r1.ebuild: EAPI=5. Implement sub-slots. Switch to python-utils-r1.eclass.
We should add the slot-operator deps to the chromium ebuilds on the next version bump for the dev and beta channels.
(In reply to comment #9) > We should add the slot-operator deps to the chromium ebuilds on the next > version bump for the dev and beta channels. chromium-25.0.1349.2 dev channel done. I think we can close this. Thank you for starting this effort, testing it, and all the work on it!
