Some eclasses and ebuilds expect LINGUAS (and possibly others) to be an environment variable even if they are not provided in the IUSE variable (#581382) According to the PMS, there is no need to export USE_EXPAND variables to the ebuild. Paludis does not export USE_EXPAND variables as environment variable: http://paludis.exherbo.org/trac/ticket/1343 It should be clearly documented in the PMS what environment variables must be provided by the package manager and which variables could be used safely by the ebuilds. Reproducible: Always
I believe that PMS section 11.1.1 (https://projects.gentoo.org/pms/6/pms.html#x1-11900011.1.1) is already quite clear on this point: "For EAPIs listed in table 5.2 as supporting profile defined IUSE injection, the variables named in USE_EXPAND and USE_EXPAND_UNPREFIXED shall have their profile-provided values reduced to contain only those values that are present in IUSE_EFFECTIVE."
I think the assignee here should be pms-bugs@gentoo.org instead of devmanual
I guess the issue being raised in bug #581382 is that we're removing translations that are not required based on the contents of LINGUAS, but without any linguas_foo in IUSE (similar behaviour to autotools I believe). This works fine in Portage since LINGUAS from make.conf is available to the ebuild, but fails in Paludis who believe that to be an illegal behaviour.
Either the PMS defines the variables like LINGUAS as required environment variable, that has to be provided by the PM, or the devmanual should make clear, that eclasses and ebuilds may not depend on any these variables. I opened this bug because of https://bugs.gentoo.org/show_bug.cgi?id=581382#c6 As Mike said: "Anyway, it would definitely be good to clarify what the PM behavior should be here." IMHO the eclasses and ebuild should include "linguas_xxx" in IUSE, as the user should see that there are translations, which translations, and it should be possible to enable or disable translations per package in a simple way.
As Ulrich has already pointed out, this is well-defined since EAPI 5. The variables named by USE_EXPAND can only contain the values that are listed in IUSE. Furthermore, any reliance on LINGUAS outside IUSE is a serious QA violation. It means that the contents of a package (and a binary package) randomly differs depending on some environmental variable that is not recorded or maintained in ebuild scope.
(In reply to Michał Górny from comment #5) > Furthermore, any reliance on LINGUAS outside IUSE is a serious QA violation. > It means that the contents of a package (and a binary package) randomly > differs depending on some environmental variable that is not recorded or > maintained in ebuild scope. There are hundreds of ebuilds using autotools that are having "serious QA violations" then. Also, other environment variables (like CFLAGS) also affect package content. This is defined outside of ebuild scope.
What does Portage do? Does it pass USE_EXPAND variables to the ebuild environment unchanged, or does it reduce their values to those that are in IUSE_EFFECTIVE?
(In reply to Ulrich Müller from comment #7) > What does Portage do? Does it pass USE_EXPAND variables to the ebuild > environment unchanged, or does it reduce their values to those that are in > IUSE_EFFECTIVE? Portage behavior is a bit quirky. Here's how I understand it: If IUSE does not contain any linguas_xxx flags, the LINGUAS envvar is not modified at all. That means you end up with whatever the literal value in make.conf is set to. If IUSE contains one or more linguas_xxx flags, the LINGUAS envvar is modified according to the rules in PMS.
I guess I would like some clarification on whether portage's behavior when IUSE contains no USE_EXPAND values is legal/undefined/illegal according to PMS.
Well, I'd say it's illegal taking the wording in PMS. And I'm pretty sure Ciaran will confirm that it's the intent.
(In reply to Michał Górny from comment #10) > Well, I'd say it's illegal taking the wording in PMS. And I'm pretty sure > Ciaran will confirm that it's the intent. Oh, and he already did in the linked report. So yep, a bug in Portage.
(In reply to Michał Górny from comment #11) > So yep, a bug in Portage. Reassigning.
We have a patch here: https://archives.gentoo.org/gentoo-portage-dev/message/42e3a134d14e33e037e35e6c5df9d05d And a discussion about the implications here: https://archives.gentoo.org/gentoo-dev/message/a08ea09c2c8e534fd9bc1146703c66ff
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=fa3f1ba8153644e07be3215d8862522a0de12134 commit fa3f1ba8153644e07be3215d8862522a0de12134 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2016-05-21 06:54:19 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-02-05 19:25:14 +0000 portage.package.ebuild.config: Always export filtered USE_EXPAND vars Ensure that all USE_EXPAND variables are always exported with filtered USE flags inside, even if none of those flags are declared in IUSE. This is the behavior required for EAPI 5+ by the PMS. Since the behavior for earlier EAPIs is left undefined and having different behavior would be confusing to users, apply it in earlier EAPIs as well. Bug: https://bugs.gentoo.org/582140 Closes: https://github.com/gentoo/portage/pull/254 Reviewed-by: Zac Medico <zmedico@gentoo.org> bin/ebuild.sh | 8 +----- pym/portage/package/ebuild/config.py | 55 ++---------------------------------- 2 files changed, 4 insertions(+), 59 deletions(-)}
Fixed in portage-2.3.40-r1.
