Re: [gentoo-dev] Re: Monthly Gentoo Council Reminder for April

[Brian Harring <ferringb@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3757 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]