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
I am using sys-apps/portage 2.3.24-r1 ACCEPT_KEYWORDS="amd64 ~amd64"
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
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?
(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.
*** Bug 659492 has been marked as a duplicate of this bug. ***
(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.
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).