| 1 |
On Thu, Feb 22, 2007 at 09:04:04AM +0100, Christian Faulhammer wrote: |
| 2 |
> Stefan Schweizer <genstef@g.o>: |
| 3 |
> |
| 4 |
> > Sadly this feature was removed from portage again - nice to see it |
| 5 |
> > coming up again. Please fix or point out ebuilds that are broken. |
| 6 |
> |
| 7 |
> Yep. Could someone compile a list (with the names of maintainers, if |
| 8 |
> possible). |
| 9 |
|
| 10 |
Offhand, tracking the metadata the ebuild exports (SLOT, RESTRICT, |
| 11 |
etc) is the easiest way to spot the offenders- typically it's |
| 12 |
interaction between eclass and ebuild differing when the ebuild is |
| 13 |
actually sourced for building. |
| 14 |
|
| 15 |
Example would be java-vm's VMHANDLE var; most ebuilds set SLOT below |
| 16 |
inherit, thus VMHANDLE is ${PN}; both portage and pkgcore export SLOT |
| 17 |
into the setup environment (annoyingly, ebuilds expect it) thus |
| 18 |
enabling VMHANDLE to be correct for the setup phase. |
| 19 |
|
| 20 |
With paludis, SLOT isn't exported; thus VMHANDLE is always ${PN} for |
| 21 |
setup phase for them. Post setup phase, the var gets reset due to |
| 22 |
their forced re-sourcing of the ebuild/eclass for every phase, thus |
| 23 |
the value comes around as proper the second time, but first time |
| 24 |
around, it's not set correctly. |
| 25 |
|
| 26 |
Personally, portage behaviour I'd say rules out there; that said, the |
| 27 |
eclass is 'special' anyways, since unless the ebuild explicitly forces |
| 28 |
SLOT prior to the inheriting, the design of it allows VMHANDLE to very |
| 29 |
between inherits when it shouldn't. |
| 30 |
|
| 31 |
In the past, easiest way I found to deal with this issue (and general |
| 32 |
metadata nonconstant violations) is auditing eclasses, looking for |
| 33 |
variables that can toggle state between phases instead of remaining |
| 34 |
constant. Trace out those vars, and you'll spot the screwups. |
| 35 |
|
| 36 |
~harring |
Archives