On Thu, Feb 22, 2007 at 09:04:04AM +0100, Christian Faulhammer wrote: > Stefan Schweizer <[EMAIL PROTECTED]>: > > > Sadly this feature was removed from portage again - nice to see it > > coming up again. Please fix or point out ebuilds that are broken. > > Yep. Could someone compile a list (with the names of maintainers, if > possible).
Offhand, tracking the metadata the ebuild exports (SLOT, RESTRICT,
etc) is the easiest way to spot the offenders- typically it's
interaction between eclass and ebuild differing when the ebuild is
actually sourced for building.
Example would be java-vm's VMHANDLE var; most ebuilds set SLOT below
inherit, thus VMHANDLE is ${PN}; both portage and pkgcore export SLOT
into the setup environment (annoyingly, ebuilds expect it) thus
enabling VMHANDLE to be correct for the setup phase.
With paludis, SLOT isn't exported; thus VMHANDLE is always ${PN} for
setup phase for them. Post setup phase, the var gets reset due to
their forced re-sourcing of the ebuild/eclass for every phase, thus
the value comes around as proper the second time, but first time
around, it's not set correctly.
Personally, portage behaviour I'd say rules out there; that said, the
eclass is 'special' anyways, since unless the ebuild explicitly forces
SLOT prior to the inheriting, the design of it allows VMHANDLE to very
between inherits when it shouldn't.
In the past, easiest way I found to deal with this issue (and general
metadata nonconstant violations) is auditing eclasses, looking for
variables that can toggle state between phases instead of remaining
constant. Trace out those vars, and you'll spot the screwups.
~harring
pgpZ8LjnbsVZ7.pgp
Description: PGP signature
