[gentoo-portage-dev] QA Notice: ECLASS 'foo' inherited illegally

[Duncan]

I continue to see way more of these than I'm comfortable with. 
"Illegally" implies the functionality will eventually go away, and stuff
will quit working.  That what's making me uncomfortable.

Some time ago this came up on the dev list and I asked about bugging them
at that time.  The reply was effectively "not yet".  Are the notices now
to be considered bugs and filed as such, or is there perhaps something
portage doesn't like in my layout?


I'm running current ~amd64, portage-2.1-pre9-r4 at this moment.  I make
heavy use of the "source" command in make.conf to modularize my settings. 
Here's the filesystem settings (BTW, with 8 gig of memory, /tmp/ is a
tmpfs that seldom sees swap):

$cat /etc/portage/make.conf/fs
PORTDIR=/p
PORTDIR_OVERLAY=/l/p
PORT_LOGDIR=/log/portage

DISTDIR=${PORTDIR}/src
PKGDIR=/pkg

# scratch dirs
PKG_TMPDIR=/tmp
PORTAGE_TMPDIR=/tmp
PORTAGE_TMPFS="/dev/shm"

# portage tools paths
CCACHE_DIR="/str/ccache"
CCACHE_SIZE="2G"
#UNSERMAKE=/usr/kde/unsermake/unsermake

Also of interest:

$cat /etc/portage/make.conf/features
# normal
FEATURES="buildpkg candy confcache ccache -metadata-transfer multilib-strict parallel-fetch sandbox userfetch"
# minus multilib-strict
#FEATURES="buildpkg candy confcache ccache -metadata-transfer parallel-fetch sandbox userfetch"
# minus ccache confcache
#FEATURES="buildpkg candy -confcache -ccache -metadata-transfer multilib-strict parallel-fetch sandbox userfetch"
# s/sandbox/userpriv/
#FEATURES="buildpkg candy confcache ccache -metadata-transfer multilib-strict parallel-fetch userpriv userfetch"
# with metadata-transfer
#FEATURES="buildpkg candy confcache ccache multilib-strict parallel-fetch sandbox userfetch"

Here's the latest warning, the one prompting this post, from the esearch
ebuild, which one would /think/ would be fairly portage aware, given the
author's necessary knowledge of portage internals.  ([...] of course
indicates snip... a dev in one case didn't catch that and thought it was
part of the output and was /really/ confused!  =8^)

[...]
 app-portage/esearch
    selected: 0.7.1
   protected: 0.7.1-r2
     omitted: none

>>> 'Selected' packages are slated for removal.
>>> 'Protected' and 'omitted' packages will not be removed.

>>> Waiting 2 seconds before starting...
>>> (Control-C to abort)...
>>> Unmerging in: 2 1
>>> Unmerging app-portage/esearch-0.7.1...
No package files given... Grabbing a set.

QA Notice: ECLASS 'portability' inherited illegally in app-portage/esearch-0.7.1

--- !mtime obj /usr/share/man/man1/eupdatedb.1.gz
[...]
--- !empty dir /usr

QA Notice: ECLASS 'portability' inherited illegally in app-portage/esearch-0.7.1

>>> Regenerating /etc/ld.so.cache...
[...]


I've notices that these warnings occur almost entirely (if not entirely)
during the unmerge phase.  Some stray comment I saw somewhere lead me to
believe they may be the result of FEATURES=buildpkg, or perhaps that
combined with the non-default filesystem layout (configuration above).  If
that's the case, then it's either not a bug, or most likely a bug with
portage, not the various ebuilds.

So... if it's a bug, do I file it on portage or the ebuilds displaying the
warning?  If it's not a bug, may at least I ask for a brief explanation of
what the warning means so I can stop worrying about it... and feeling
guilty for ignoring the warning and not filing the bugs!  =8^)

Or... is it still "not yet a bug to file about"?  In that case, the brief
explanation would still be very much appreciated.  =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html

-- 
gentoo-portage-dev@g.o mailing list