portage 2.1_rc1-r3. portage.config.__init__ has (ll 1138-1145): abs_user_config = os.path.join(config_root, USER_CONFIG_PATH.lstrip(os.path.sep)) locations = [os.path.join(self["PORTDIR"], "profiles"), abs_user_config] for ov in self["PORTDIR_OVERLAY"].split(): ov = os.path.normpath(ov) if os.path.isdir(ov+"/profiles"): locations.append(ov+"/profiles") This means that profiles/package.mask in overlays comes later in the stack than /etc/portage/package.mask, so /etc/portage cannot remove lines from the stack or readd lines the overlay profiles/package.mask removes. Suggest put /etc/portage after overlay profiles/ in stack. Patch to follow.
/etc/portage/ isn't supposed to be in the stack at all
Created attachment 87027 [details, diff] portage-stack-etc-last.patch
(In reply to comment #1) > /etc/portage/ isn't supposed to be in the stack at all Not for most profile stuff, sure, but it is for package.mask. Has been at least since the migrate to svn.
The stacking order and incremental behavior is currently undocumented, which is bad, so we need to document it. Currently, the order is as follows: 1) /etc/make.profile (parents followed by children) 2) /etc/portage/profile 3) $PORTDIR/profiles 4) /etc/portage 5) $PORTDIR_OVERLAY/profiles (from left to right) Here is a new proposed order: 1) $PORTDIR/profiles 2) /etc/make.profile (parents followed by children) 3) /etc/portage/profile 4) $PORTDIR_OVERLAY/profiles (from left to right) 5) /etc/portage Feedback?
Hmm. I'd argue that: a) PORTDIR/profiles and OVERLAY/profiles are similar in concept, so should be adjacent in the stack, with OVERLAY/profiles later b) /etc/portage needs to be able to override anything, so should go last in the stack c) Only advanced users will know what to do with /etc/portage/profile, so it should go after PORTDIR and OVERLAYs d) make.profile typically points to a profile in PORTDIR, so OVERLAY/profiles should go after make.profile This gives: 1. /etc/make.profile (parents before children) 2. $PORTDIR/profiles 3. $PORTDIR_OVERLAY/profiles (left-to-right) 4. /etc/portage/profile 5. /etc/portage
(In reply to comment #5) > Hmm. I'd argue that: > a) PORTDIR/profiles and OVERLAY/profiles are similar in concept, so should be > adjacent in the stack, with OVERLAY/profiles later I'd say usefulness should weigh more than things being "similar in concept". > b) /etc/portage needs to be able to override anything, so should go last in > stack Agreed. > c) Only advanced users will know what to do with /etc/portage/profile, so it > should go after PORTDIR and OVERLAYs /etc/portage/profile is the last of the profile stack (see python -c 'import portage; print portage.settings.profiles') so I think it should come after make.profile. > d) make.profile typically points to a profile in PORTDIR, so OVERLAY/profiles > should go after make.profile Well, OVERLAY/profiles has nothing to do with make.profile. It's more similar to $PORTDIR/profiles and /etc/portage (none of which are part of a profile per se). Don't let the directory name "profiles" make you think that it has anything to do with a profile. That just happens to be the location of the global package.mask file for the repo.
(In reply to comment #6) > /etc/portage/profile is the last of the profile stack (see python -c 'import > portage; print portage.settings.profiles') so I think it should come after > make.profile. Ah. Yeah, good point. The issue I have with $PORTDIR/profiles and $PORTDIR_OVERLAY/profiles being nonadjacent is that I can see a Gentoo dev working in an overlay and then being surprised when things don't behave as expected when that overlay is folded into the main gentoo-x86 tree. That suggests: 1. /etc/make.profile (parents before children) 2. /etc/portage/profile 3. $PORTDIR/profiles 4. $PORTDIR_OVERLAY/profiles (left-to-right) 5. /etc/portage However, I can see that arch devs would want to be able to (in extremis) override $PORTDIR/profiles with the /etc/make.profile tree. OK: arch devs need to be able to override $PORTDIR/profiles; /etc/portage/profile is the end of the /etc/make.profile stack; overlay writers need to be able to override all the $PORTDIR machinery. And /etc/portage is the last word. This means your proposed order in comment 4 is correct. Thanks for bearing with me on this.
This is fixed in svn r3495.
This has been released in 2.1.1_pre1.
(In reply to comment #8) > This is fixed in svn r3495. Via gitweb: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=4590565f93f6c5be8269e0c322960d18929a0fd6
There's a new order in git now: config from other repos than PORTDIR comes before profiles (like PORTDIR) http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=ca9a73ad87b56f0997b566f24f251dbe345389fd And there's a related commit for bug 336692 here: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=cc129641968902ff8e791a840dff339e45632a0f
