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

[Brian Harring]

On Fri, Apr 06, 2007 at 12:16:18AM +0200, Danny van Dyk wrote:
> > > * There is at least one outstanding QA issue that i know of which
> > > is related to Portage and can't be fixed w/o slot deps properly.
> > > Read: KDE's problems with ranged deps and the way it currently
> > > breaks the vdb's RDEPEND entries, especially regarding qt and
> > > kdelibs.
> >
> > Elaborating a bit, this actually is only a problem for pkgcore and
> > paludis; portage isn't affected since it prefers to try pulling the
> > metadata from $PORTDIR; reasoning is that way screw ups in the
> > metadata that are now locked in the vdb can be worked around via it.
> AFAIK zmedico spoke about moving portage to use vdb metadata instead.
> Before this could happen we needed a fix for it.

Suspect zac could confirm that's it's about weekly now for me nagging 
him about gutting that ;)


> > You can trigger the same issue in portage via wiping pretty much
> > everything in PORTDIR (switching the tree, or just a literal rm of
> > everything but profiles crap), but that's fairly corner case.
> >
> > Don't much like the behavior myself, but updates/* would need
> > expansion to address the (massively long term) reasoning for portages
> > behavior.  Upshot, running from vdb only instead of the dual lookup
> > would speed up portages resolution via less IO/parsing...
> >
> > Either way, the kde/qt issue was known from the get go- since slot
> > deps weren't available when they started down this path, they should
> > have used new style virtuals instead.  Yes it's ugly, backwards
> > compatibility usually isn't utterly pretty- upshot of it however is
> > that the upgrade node is just a new style virtual, no real cost for
> > the operation.
> >
> > 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.

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 
example, hell, making the default phase functions into an eclass 
equivalent template.  Clarifying, instead of
src_compile() {
	default src compile crap
}

would do
base_src_compile() {
	default src compile crap
}

That way if you just need to tweak one thing, you can still use the 
default src_compile- basically same trick EXPORT_FUNCTIONS does.

Either way, EAPI=1 *should* have a bit more then just slot deps in my 
opinion; very least it needs discussion to discern what folks want.


> > months" would apply here at the very least.  The problem is that
> > 2.1.2 is the first portage version to have slot deps- that is a
> > fairly recent stabling, so there still would be a good chunk of time
> > to wait *if* the daft old method of just shoving stuff in and
> > watching things break was took.
>
> What breakage specifically? Portage versions that don't support EAPI?

Breakage there I'm referring to trying to is a set of folks 
trying to shove it into EAPI=0.


> > Meanwhile, worth remembering during the interim while slot deps
> > aren't usable, new style virtual does address it (even if it's a
> > gross trick)
>
> I prefer we solve this problem instead of hacking around it once more.

Even with EAPI=1 route, still going to require some time to actually 
address it- have to define EAPI=1, make sure portage supports it 
fully, make sure it's stable for all arches, etc.  That's a several 
month proceess, best case, 30 days if somehow everyone agrees to 
eapi=1 today, zac implements it tonight, and releases it tomorrow 
morning (with no bugs).

So... again- it's not pretty, but it's not an issue that's going to be 
solved tomorrow, so it's not a bad idea to take a look at ways to work 
around it.  Very least, if the new style virtual route was taken, 
switching over to slot deps (when available) would be easy- update the 
virtual, then start pruning the tree for anything depending on the 
virtual.

~harring