Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 582140 - Portage does not reduce values of USE_EXPAND variables to IUSE_EFFECTIVE in some cases
Summary: Portage does not reduce values of USE_EXPAND variables to IUSE_EFFECTIVE in s...
Status: RESOLVED FIXED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Ebuild Support (show other bugs)
Hardware: All Linux
: Normal major (vote)
Assignee: Portage team
URL: https://projects.gentoo.org/pms/6/pms...
Whiteboard:
Keywords: InVCS
Depends on:
Blocks: 563798 651804
  Show dependency tree
 
Reported: 2016-05-05 10:15 UTC by Thomas Berger
Modified: 2018-07-02 18:39 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Berger 2016-05-05 10:15:01 UTC
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
Comment 1 Ulrich Müller gentoo-dev 2016-05-05 14:43:36 UTC
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."
Comment 2 Göktürk Yüksek gentoo-dev 2016-05-05 14:58:53 UTC
I think the assignee here should be pms-bugs@gentoo.org instead of devmanual
Comment 3 Michael Palimaka (kensington) gentoo-dev 2016-05-05 16:10:05 UTC
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.
Comment 4 Thomas Berger 2016-05-05 16:33:33 UTC
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.
Comment 5 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-05-05 16:53:33 UTC
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.
Comment 6 Mike Gilbert gentoo-dev 2016-05-05 17:45:54 UTC
(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.
Comment 7 Ulrich Müller gentoo-dev 2016-05-05 17:52:30 UTC
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?
Comment 8 Mike Gilbert gentoo-dev 2016-05-05 18:26:14 UTC
(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.
Comment 9 Mike Gilbert gentoo-dev 2016-05-05 18:34:07 UTC
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.
Comment 10 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-05-05 18:53:47 UTC
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.
Comment 11 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2016-05-05 18:55:04 UTC
(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.
Comment 12 Ulrich Müller gentoo-dev 2016-05-05 19:10:09 UTC
(In reply to Michał Górny from comment #11)
> So yep, a bug in Portage.

Reassigning.
Comment 14 Larry the Git Cow gentoo-dev 2018-02-05 19:25:33 UTC
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(-)}
Comment 15 Zac Medico gentoo-dev 2018-07-02 18:39:54 UTC
Fixed in portage-2.3.40-r1.