On Sun, Jan 30, 2005 at 04:30:15AM -0700, Duncan wrote: > What about the "improper inheritance if eclass" or whatever errors I often > see during the unmerge of old packages after an update? When the question > last came up (in general, not on unmerging packages), the answer was the > system wasn't quite ready to handle the deluge of such errors just yet. > It was new to portage and in a version still hard masked at the time for > testing, Long story short, portage is confused (rightfully so) by it's own previous actions. Those checks are based in the inherit function, when asked to inherit an eclass and it's not either the depends phase (get cache keys), or setup phase (run pkg_setup), it checks the INHERITED var (iirc). If the desired eclass to inherit isn't listed in that var, it assumes it's encountered a conditional inherit- something like
use debug && inherit debug which, is completely invalid. Eclass inheritance isn't conditional, you either use the eclass, or you don't- always. The check you're hitting is checking for trickery of this sort. So... the problem is that the bash side of portage either A) is whacked out, and didn't properly reload the saved env for pkg_(pre|post)rm phases (this actually is pretty common, and fixed in non-stable cvs), B) portage's cached keys are whacked out, and it's pushing an invalid INHERITED setting into the env (less common then A, but still happens a lot), C) you just hit a conditional inherit in the tree, and it properly identified it. Relatively uncommon, but happens with older ebuilds that have been merged- the tree (now) should be clean of cond. inherits, in the past that wasn't the case. So. turned out it wasn't quite a short description, ignore it. :) Next major release, complaints of that sort won't have any false positives for the most part, current stable, it happens a lot on unmerges unfortunately. > IIRC. However, since then I've continued to see the QA Notice > message, but most of the time during an unmerge of an old package after an > update to a newer version. Thus, I've figured it's getting the old > packages out of the way and it's not worth reporting those QA Notices on > those old packages. Is that correct, or at least for someone generally > keeping up with ~arch (in my case ~amd64), should I be reporting those on > unmerges as well, now? Hard to state. If you hit those errors merging, report them. Unmerging, the environment that could runs in is a bit faulty, so it's possible portage is being stupid/generating false positives. Basically, if I saw those messages on an unmerge, and the ebuild was recently added to the tree, I'd check the tree to see if that specific version still exists, and look for the errors portage spat. It's possible they're still there, although again, entirely possible it's portage screwing up (likely imo) for unmerge related phases. ~brian -- [email protected] mailing list
