Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 647592 - sys-apps/portage: USE="${USE} ..." give confusing results in make.defaults and make.conf
Summary: sys-apps/portage: USE="${USE} ..." give confusing results in make.defaults an...
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 659492 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-02-14 11:48 UTC by Markus Rathgeb
Modified: 2021-04-09 22:51 UTC (History)
1 user (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 Markus Rathgeb 2018-02-14 11:48:26 UTC
I have a problem with the precedence between make.defaults and package.use of a profile.
Shouldn't the package.use be more important than make.default?

At least my observation has been that this was the behavior for years.
Perhaps my system gets broken or I miss some point now, but it does not work for me anymore.



I created a very simple demo to reproduce what I mean:

Set make.profile

# rm /etc/portage/make.profile; ln -s /usr/portage/profiles/default/linux/amd64/17.0/systemd /etc/portage/make.profile

Using that setup busybox will be installed with the static USE flag and without the "pam" USE flag.
This is the intended behavior because there is a conflict between "static" and "pam" for busybox.

All fine

Then let's create a custom profile that:
* uses the above one as parent
* enable the "pam" USE flag globally
* disable the "pam" USE flag for busybox

mkdir /var/lib/portage/my_test_profile
echo '/usr/portage/profiles/default/linux/amd64/17.0/systemd' > /var/lib/portage/my_test_profile/parent
echo '5' > /var/lib/portage/my_test_profile/eapi
echo 'USE="${USE} pam"' > /var/lib/portage/my_test_profile/make.defaults
echo 'sys-apps/busybox -pam' > /var/lib/portage/my_test_profile/package.use

# rm /etc/portage/make.profile; ln -s /var/lib/portage/my_test_profile /etc/portage/make.profile

Using that setup busybox would like to be installed with the static USE flag and with the "pam" USE flag.
That does not work because the required use constraints are unsatisfied.
But it is also not what I would expect.

Reproducible: Always
Comment 1 Markus Rathgeb 2018-02-14 11:58:08 UTC
I am using sys-apps/portage 2.3.24-r1
ACCEPT_KEYWORDS="amd64 ~amd64"
Comment 2 Zac Medico gentoo-dev 2018-02-14 18:28:09 UTC
It works correctly for me, so it looks like you have an overriding configuration in one of these files:

/etc/portage/make.conf
/etc/portage/package.use

/etc/portage/profile/make.default
/etc/portage/profile/package.use
/etc/portage/profile/package.use.force
/etc/portage/profile/use.force
Comment 3 Markus Rathgeb 2018-02-14 18:39:48 UTC
Thanks for the tip.
I started with an empty /etc/portage directory and added the link to the profile only. With that setup the problem does not occur.

It seems the problem is caused because my first USE= line in my make.conf looks like:
USE="${USE} ..."

If I remove the ${USE} in the value all is working.

So, I assume ${USE} contains the USE flags of the parent (in that case of my profile) and so it looks like as "pam" is set by my make.conf. My make.conf so overrides the package.use of the profile.

Does this make sense?

It is easy for me now to fix it on my side. But would it make sense if portage removes the old values in such variables before proceeding other settings?
Comment 4 Zac Medico gentoo-dev 2018-04-01 16:56:04 UTC
(In reply to Markus Rathgeb from comment #3)
> If I remove the ${USE} in the value all is working.
> 
> So, I assume ${USE} contains the USE flags of the parent (in that case of my
> profile) and so it looks like as "pam" is set by my make.conf. My make.conf
> so overrides the package.use of the profile.
> 
> Does this make sense?

Yes that's expected.

> It is easy for me now to fix it on my side. But would it make sense if
> portage removes the old values in such variables before proceeding other
> settings?

The dichotomy between incremental and non-incremental variables is problematic here, since appending to non-incremental variables may be desirable.
Comment 5 Zac Medico gentoo-dev 2018-06-28 17:07:19 UTC
*** Bug 659492 has been marked as a duplicate of this bug. ***
Comment 6 Philipp Ammann 2018-09-03 08:20:24 UTC
(In reply to Markus Rathgeb from comment #3)

A solution is to use package.use.{force,mask}. USE flags {en,dis}abled that way are not overridden (or even overridable) by subprofiles.

I have a root profile and two subprofiles (desktop,server). make.defaults in root sets USE="... minimal ...". The subprofiles set USE="${USE} ...". Thus "app-editors/vim -minimal" in the root's package.use gets overridden.

Adding

  app-editors/vim      minimal
  app-editors/vim-core minimal

to root/package.use.mask forces the flag off in all subprofiles. It's a hack, but the only other solution i found was symlinking root/package.use to root/subprof/package.use.

Personally I'd vote for changing the precedence of USE flags in profiles but i understand that this would require a massive reworking of existing profiles.
Comment 7 dkjii 2021-04-09 22:51:14 UTC
I came upon the same issue, having USE="$USE ..." as a first line in make.conf using the profile make.defaults (and use ignoring profile package.use).