Am Freitag, 6. April 2007 00:11 schrieb Brian Harring:
> > > 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.
EAPI=0 will be defined by PMS once accepted by the council
> 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.
What has that to do with slot deps? You can incremently define EAPI=2
and include it there.
> 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.
Is there any technical reason why EAPI=1 should be a major step that
includes all we want to get in/get rid off?
> > > 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.
I was not talking about that at all. And yes, i know how you are
refering to. And yes, it's up to the council to decide that.
And yes, there is a bug[1] covering it.
> > > 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).
Very well. I'd like to target this for KDE people to use it for kde-4.
> 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.
And what about the vdb RDEPENDs on said virtual? That the whole point,
sanitize the vdb metadata.
Danny
[1] https://bugs.gentoo.org/show_bug.cgi?id=170161
--
Danny van Dyk <[EMAIL PROTECTED]>
Gentoo/AMD64 Project, Gentoo Scientific Project
--
gentoo-dev@gentoo.org mailing list
