From bug #628978 # emerge -uDNa world These are the packages that would be merged, in order: Calculating dependencies |/mnt/dev/gentoo-x86/sys-devel/distcc/distcc-3.2_rc1-r5.ebuild: line 47: get_libdir: command not found /... done! happens when get_libdir is called at global scope. My reading of PMS shows that the function should be defined and return "lib". It's not really correct but then PMS should probably restrict get_libdir to phase functions and portage print a warning about this instead of trying to call a random "get_libdir" binary as root.
(In reply to Alexis Ballier from comment #0) > My reading of PMS shows that the function should be defined and return > "lib". It's not really correct but then PMS should probably restrict > get_libdir to phase functions In fact it does, in section 11.3 "Available Commands", https://projects.gentoo.org/pms/6/pms.html#x1-12600011.3: This section documents the commands available to an ebuild. Unless otherwise specified, they may be aliases, shell functions, or executables in the ebuild’s PATH. When an ebuild is being sourced for metadata querying rather than for a build (that is to say, when none of the src_ or pkg_ functions are to be called), no external command may be executed. The package manager may take steps to enforce this. Since it is not specified as what type of command get_libdir is to be implemented, the ebuild must not call it in global scope (because it could be an external executable). > and portage print a warning about this instead of trying to call a random > "get_libdir" binary as root.
(In reply to Ulrich Müller from comment #1) > (In reply to Alexis Ballier from comment #0) > > My reading of PMS shows that the function should be defined and return > > "lib". It's not really correct but then PMS should probably restrict > > get_libdir to phase functions > > In fact it does, in section 11.3 "Available Commands", > https://projects.gentoo.org/pms/6/pms.html#x1-12600011.3: > > This section documents the commands available to an ebuild. > Unless otherwise specified, they may be aliases, shell functions, > or executables in the ebuild’s PATH. > > When an ebuild is being sourced for metadata querying rather than > for a build (that is to say, when none of the src_ or pkg_ functions > are to be called), no external command may be executed. The package > manager may take steps to enforce this. > > Since it is not specified as what type of command get_libdir is to be > implemented, the ebuild must not call it in global scope (because it could > be an external executable). Not so sure, it is in '11.3.3.13 Text list functions', the same as inherit, and I don't see any difference in specification with it. > > and portage print a warning about this instead of trying to call a random > > "get_libdir" binary as root. but then again, I would feel much better with this being always defined and having an eqawarn at global scope
(In reply to Alexis Ballier from comment #2) > (In reply to Ulrich Müller from comment #1) > > (In reply to Alexis Ballier from comment #0) > > > My reading of PMS shows that the function should be defined and return > > > "lib". It's not really correct but then PMS should probably restrict > > > get_libdir to phase functions > > > > In fact it does, in section 11.3 "Available Commands", > > https://projects.gentoo.org/pms/6/pms.html#x1-12600011.3: > > > > This section documents the commands available to an ebuild. > > Unless otherwise specified, they may be aliases, shell functions, > > or executables in the ebuild’s PATH. > > > > When an ebuild is being sourced for metadata querying rather than > > for a build (that is to say, when none of the src_ or pkg_ functions > > are to be called), no external command may be executed. The package > > manager may take steps to enforce this. > > > > Since it is not specified as what type of command get_libdir is to be > > implemented, the ebuild must not call it in global scope (because it could > > be an external executable). > > Not so sure, it is in '11.3.3.13 Text list functions', the same as inherit, > and I don't see any difference in specification with it. Sorry, '11.3.3.14 Misc commands'
Also "unpack", "default", and "einstalldocs". I guess nobody would even think about calling these in global scope. ("inherit" specifically says (in section 10.1) that it is intended to be called in global scope.)
(In reply to Ulrich Müller from comment #4) > Also "unpack", "default", and "einstalldocs". I guess nobody would even > think about calling these in global scope. ("inherit" specifically says (in > section 10.1) that it is intended to be called in global scope.) "unpack" & co would fall under rule that they're explicitly defined to call external commands. get_libdir is explicitly defined as pure bash. As for inherit, I read 'An ebuild wishing to make use of an eclass does so by using the inherit command in global scope' as inherit can *only* be used in global scope, implying this is an extra restriction. I think we all agree get_libdir in global scope makes little to no sense. I tend to prefer explicit restrictions than those subject to interpretation or "common sense": I understand your reasoning but it is a bit convoluted for making that a rule. get_libdir is currently used in global scope, so I guess making this explicit cannot hurt. OTOH, portage not defining get_libdir as a warning in global scope makes it real hard to catch bugs like bug #628978 : since it uses a cache when parsing ebuilds, if you miss the 'command not found' message the first time you'll never see it again...
Giving it more thought, this might even be an emanation of a very old issue: portage sources the ebuild as EAPI-0 to get EAPI. get_libdir is thus not defined there. Do we have any rule that using any non eapi 0 function/command or dereferencing a non eapi0 variable in global scope is forbidden ? If not, this seems like a very needed QA rule.
Alexis, your thorough analysis would be welcome if you cared to do some prior research. Otherwise, every third assumption you make is simply wrong, and so are your results.
(In reply to Alexis Ballier from comment #6) > Giving it more thought, this might even be an emanation of a very old issue: > portage sources the ebuild as EAPI-0 to get EAPI. That used to be the case, but is no longer true (since 2012 already): https://gitweb.gentoo.org/proj/pms.git/diff/ebuild-vars.tex?id=86fae0e02d7b21f085ef0a3d4308b6be29332d48&id2=b1bda8eeff28d1547a689a549a9f7b20d653a087 https://projects.gentoo.org/council/meeting-logs/20120403-summary.txt
(In reply to Michał Górny from comment #7) > Alexis, your thorough analysis would be welcome if you cared to do some > prior research. Otherwise, every third assumption you make is simply wrong, > and so are your results. Please refrain from making such hateful comments that have nothing constructive to add to the discussion. See comment #8 for an example. Thank you.
(In reply to Ulrich Müller from comment #8) > (In reply to Alexis Ballier from comment #6) > > Giving it more thought, this might even be an emanation of a very old issue: > > portage sources the ebuild as EAPI-0 to get EAPI. > > That used to be the case, but is no longer true (since 2012 already): > https://gitweb.gentoo.org/proj/pms.git/diff/ebuild-vars. > tex?id=86fae0e02d7b21f085ef0a3d4308b6be29332d48&id2=b1bda8eeff28d1547a689a549 > a9f7b20d653a087 > https://projects.gentoo.org/council/meeting-logs/20120403-summary.txt Thanks. I didn't recall it had gone somewhere after all the discussions around this. However, this does not exclude a portage bug and portage sourcing the ebuild as EAPI-0. It seems it does: with PORTAGE_DEBUG=1 and an added echo EAPI=$EAPI in ebuild.sh, I get something like that: + true + set +x EAPI= + source /mnt/dev/gentoo-x86/sys-devel/distcc/distcc-3.2_rc1-r9.ebuild ++ EAPI=6 ++ PYTHON_COMPAT=(python2_7) ++ inherit autotools flag-o-matic python-single-r1 systemd toolchain-funcs user xdg-utils ++ ECLASS_DEPTH=1 ++ [[ 1 > 1 ]] ++ [[ -n '' ]]
(In reply to Alexis Ballier from comment #10) > However, this does not exclude a portage bug and portage sourcing the ebuild > as EAPI-0. It seems it does: with PORTAGE_DEBUG=1 and an added echo > EAPI=$EAPI in ebuild.sh, I get something like that: > > + true > + set +x > EAPI= > + source /mnt/dev/gentoo-x86/sys-devel/distcc/distcc-3.2_rc1-r9.ebuild > ++ EAPI=6 This is the expected behaviour. https://projects.gentoo.org/pms/6/pms.html#x1-700007.3.1 "For a recognised EAPI, the package manager must make sure that the EAPI value obtained by sourcing the ebuild with bash is identical to the EAPI obtained by parsing. The ebuild must be treated as invalid if these values are different." The EAPI variable must be unset or empty before sourcing, in order to make this double-checking possible. That doesn't imply that the ebuild is sourced as EAPI 0.
(In reply to Ulrich Müller from comment #11) > (In reply to Alexis Ballier from comment #10) > > However, this does not exclude a portage bug and portage sourcing the ebuild > > as EAPI-0. It seems it does: with PORTAGE_DEBUG=1 and an added echo > > EAPI=$EAPI in ebuild.sh, I get something like that: > > > > + true > > + set +x > > EAPI= > > + source /mnt/dev/gentoo-x86/sys-devel/distcc/distcc-3.2_rc1-r9.ebuild > > ++ EAPI=6 > > This is the expected behaviour. > > https://projects.gentoo.org/pms/6/pms.html#x1-700007.3.1 > "For a recognised EAPI, the package manager must make sure that the EAPI > value obtained by sourcing the ebuild with bash is identical to the EAPI > obtained by parsing. The ebuild must be treated as invalid if these values > are different." > > The EAPI variable must be unset or empty before sourcing, in order to make > this double-checking possible. Indeed. > That doesn't imply that the ebuild is sourced > as EAPI 0. That's what I don't understand: If it was parsed as EAPI-6, get_libdir should be defined, which is not the case here.
(In reply to Alexis Ballier from comment #12) > That's what I don't understand: If it was parsed as EAPI-6, get_libdir > should be defined, which is not the case here. I haven't looked into the code, but I would guess that Portage defines get_libdir() as a "phase helper". So the function won't be defined in global scope.
(In reply to Ulrich Müller from comment #13) > (In reply to Alexis Ballier from comment #12) > > That's what I don't understand: If it was parsed as EAPI-6, get_libdir > > should be defined, which is not the case here. > > I haven't looked into the code, but I would guess that Portage defines > get_libdir() as a "phase helper". So the function won't be defined in global > scope. You're right. It's in phase-helpers.sh. The only global scope function that would make sense here is in_iuse but then PMS specifically bans it from global scope (note: there are some violations in eclasses for example). Not sure what could be a good way moving forward with this: - PMS is fine as-is - get_libdir at global scope is a QA violation - portage should catch and report those violations or: - PMS should ban get_libdir at global scope, the same way as e.g. in_iuse - portage should catch and report loudly those usages
Portage git now fails verbosely when get_libdir is used in global scope.
Remove ComRel, this is unclear what we expected to do here.
Not sure what would be the role of QA in this bug, therefore reassigning to Portage team.
(In reply to Michał Górny from comment #15) > Portage git now fails verbosely when get_libdir is used in global scope. Thanks!
