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
pgpUYtZfJCyM1.pgp
Description: PGP signature
