On Fri, Apr 06, 2007 at 12:41:50AM +0200, Vlastimil Babka wrote: > Brian Harring wrote: > >>> Breaking EAPI=0 via pushing slot deps in isn't much of an option in > >>> my opinion; usual "needs to have been on release media for at least 6 > >> We can push for an EAPI=1 == (EAPI=0 + slot deps)... > > > > Can, yep, although that was originally blocked by "EAPI=0 must be > > defined", which folks seem to have backed off on. > > Not sure if slot deps themselves could even replace version ranges hacks > without also solving bug 4315 (native version ranges) in all cases. IMHO > it should be possible at least to specify slot+usual version limit, to > make it worth EAPI bump. > > > One issue with adding EAPI=1 having just slot deps is that it skips > > out on some long term changes intended- default src_install for > > So what, longer term changes could wait for EAPI=2. Why not make > experience with EAPI bumping with something smaller for a start, instead > of trying to make one big bump that will bring all changes we can think > of now, but will be implemented only in 2010...
A 101 small little bumps results in a general pain in the ass for ebuild devs; if a change is ready to go for EAPI=1 (whether implemented now, or bloody simple), and folks *agree to it*, then it should go in. I'm not advocating waiting for every little thing to be shoved in. That said, there are lots of minor tweaks that have been desired, but haven't been implementable since they would break backwards compatibility and no versioning scheme existed. I've got a list floating around somewhere of the specifics, but top of the head- 1) killing DEPEND/RDEPEND autosetting once and for all 2) shift the default phase funcs into a fake eclass; basically the base_src_compile example in the previous email. 3) default src_install (currently is empty) 4) *potentially* chunking up src_compile into src_configure and src_compile. 5) slightly addressed via #2, a 'prepare phase' for patching and other crap. Not a huge fan, but it's also not something I'm pushing. 6) drop useq/hasq 7) whatever api additions required to remove the need for raw vdb access by ebuilds (contents, IUSE, and USE seem to be the primary ones atm till use deps are available). 8) potential, although it requires work- glep33. I'd probably be willing to do the portage modifications for that one; upshot of it is that it allows breaking eclass api as needed, further reorganizes their on disk layout so signing/manifests can sanely be integrated. So... #8 is slightly large admittedly. Rest are pretty damn minor, bit of discussion required, but minimal real work to code it- stuff like that, no reason *not* to slide it into eapi=1. > Now it may look like I contradict myself saying to bump ASAP but not > without solving bug 4315 first. But I see slot deps without limits only > half of a feature. So far, the syntax I've seen for 4315 has made me want to club baby seals, hit the hash pipe, and make a run for the presidency... Offhand, majority of the tree issues can be addressed via slot deps- the remaining chunks that can't, can be addressed via a slightly smarter resolver combined with folks using blockers- simple example, need >=1.3 < 2.0 for a non-slotted package, use ">=1.3 !>2.0". Can invert it to "<2.0 !<1.3" if you prefer, although the latter is slightly preferable on the offchance the package some day becomes slotted. Granted, it's not perfect- point is it's actually doable now without format changes. Other question there is how many ebuilds in the tree actually *need* this, beyond just slot deps. Either way, folks ought to chime in... ~harring
pgpmqvRrJjXxB.pgp
Description: PGP signature
