| 1 |
On Mon, Apr 24, 2006 at 04:10:50AM -0700, Duncan wrote: |
| 2 |
> I continue to see way more of these than I'm comfortable with. |
| 3 |
> "Illegally" implies the functionality will eventually go away, and stuff |
| 4 |
> will quit working. That what's making me uncomfortable. |
| 5 |
> |
| 6 |
> Some time ago this came up on the dev list and I asked about bugging them |
| 7 |
> at that time. The reply was effectively "not yet". Are the notices now |
| 8 |
> to be considered bugs and filed as such, or is there perhaps something |
| 9 |
> portage doesn't like in my layout? |
| 10 |
<snip> |
| 11 |
> I've notices that these warnings occur almost entirely (if not entirely) |
| 12 |
> during the unmerge phase. Some stray comment I saw somewhere lead me to |
| 13 |
> believe they may be the result of FEATURES=buildpkg |
| 14 |
|
| 15 |
bug 56408 ( http://bugs.gentoo.org/56408 ). |
| 16 |
|
| 17 |
When it's a (99% of the time) a valid bug- |
| 18 |
1) If you see it during unpack -> install, it's a bug in the ebuild. |
| 19 |
2) If you see it during setup when *building* a package, it's a bug in |
| 20 |
the ebuild. |
| 21 |
|
| 22 |
When it's (typically) not a valid bug in the ebuild- |
| 23 |
1) binpkg merging, setup phase. |
| 24 |
2) (pre|post)(inst|rm) |
| 25 |
3) config phase. |
| 26 |
4) When you've gone and screwed with PORTAGE_TMPDIR location, or |
| 27 |
wiped the env file when walking through the phases. |
| 28 |
|
| 29 |
Basically, portage doesn't always reuse the saved env properly- since |
| 30 |
the check relies on a proper env, it gets false positives. |
| 31 |
|
| 32 |
Fixing up the env handling is problematic- basically, that env _needs_ |
| 33 |
to be reused (both the relevant portage snippets of it, and eclass). |
| 34 |
|
| 35 |
You can address the eclass issue by just copying the eclasses around |
| 36 |
with the ebuild (in affect, duplicating the eclass code when you've |
| 37 |
already got the env state), but that's pointless- just fix the |
| 38 |
env handling so it runs from the preserved state. |
| 39 |
|
| 40 |
That leaves effectively the portage api side of it- fex, use must |
| 41 |
work the same regardless of portage version (or if it changes, be |
| 42 |
versioned by eapi fex to denote the break in compatibility). Why does |
| 43 |
this matter? Older versions of portage had use echo to stdout if it |
| 44 |
matched (hence [ -n "$(use blah)" ] tests), if you change in portage |
| 45 |
use's behaviour (to rely on return code instead of echo'ing), older |
| 46 |
ebuild/saved envs won't function properly anymore. |
| 47 |
|
| 48 |
Sordid details are in the bug (fun sidenote, that bug holds a *really* |
| 49 |
old version of ebd before I daemonized it) :) |
| 50 |
|
| 51 |
~harring |
Archives