Adding the overlay gnome-next, which has profiles/package.unmask set (which I consider a bad behaviour, but this is tracked as bug 624864), I noticed this is overwriting my local package.mask: Any /etc/portage/package.mask/* with */*::gnome-next is just ignored. I set this line for every unofficial overlay for not implicitly updating to versions from the overlay. This seems more like a portage bug, that overlay profiles have precedence over /etc/portage/ . Reproducible: Always
It's an overlay bug, not a Portage bug.
Is there some way to prevent overlay profile files overriding /etc/portage files? It looks obvious (my imho), that this stuff should follow same rules as ebuild preference - overlay/portage priority, and never override /etc/portage stuff. Example precedence with "overlay" priority over portage could be this: etc_unmask; etc_mask; overlay_unmask;overlay_mask;portage_unmask;portage_mask; If e.g. (not actually) <=app-editors/gedit-3.28 is written to gnome-next/profile/package.unmask, but /etc/portage/package.mask has ~app-editors/gedit-3.20, then =app-editors/gedit-3.20 of any revision must be latest unmasked version. I hope it will not be felt personally. Current precedence scheme is itself bug.
Lua overlay also causes problems in the same way. (In reply to Andreas Sturmlechner from comment #1) > It's an overlay bug, not a Portage bug. If this is an “overlay bug” then the portage(5) manpage should stop advertising it as a feature, and QA checks should be catching it. Why aren't they?
(In reply to Nikita Zlobin from comment #2) > Example precedence with "overlay" priority over portage could be this: > etc_unmask; etc_mask; > overlay_unmask;overlay_mask;portage_unmask;portage_mask; Yes, offhand I think that could give good results. (In reply to Anthony Parsons from comment #3) > Lua overlay also causes problems in the same way. > > > (In reply to Andreas Sturmlechner from comment #1) > > It's an overlay bug, not a Portage bug. > > If this is an “overlay bug” then the portage(5) manpage should stop > advertising it as a feature, and QA checks should be catching it. Why aren't > they? Please speak up if you foresee any problems that would not be solved by enabling /etc/portage/package.mask to override package.unmask in overlays.
Added myself, while trying to install gnome-extra/budgie-desktop 1. Proper masking, i.e */*::gnome-next results in: (during an emerge -uDavN --with-bdeps=y @world), before emerging budgie. These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild N ] media-libs/exempi-2.4.5-r1:2/3::gentoo USE="-examples -static-libs -test" 0 KiB [ebuild N ] app-i18n/uchardet-0.0.6-r2::gentoo USE="-static-libs -test" CPU_FLAGS_X86="sse2" 0 KiB [ebuild U #] gnome-extra/yelp-xsl-3.34.2::gnome-next [3.32.1::gentoo] 0 KiB [ebuild r U #] gnome-base/libgtop-2.40.0:2/10::gnome-next [2.38.0:2/11::gentoo] USE="introspection" 0 KiB [ebuild U #] x11-libs/libwnck-3.32.0:3::gnome-next [3.30.0:3::gentoo] USE="introspection startup-notification tools" 0 KiB [ebuild N ] gui-libs/amtk-5.0.1:5::gentoo USE="introspection" 0 KiB [ebuild rR ] gnome-extra/gnome-system-monitor-3.32.1::gentoo USE="X systemd" 0 KiB [ebuild U #] x11-libs/gtk+-2.24.32-r666:2::gnome-next [2.24.32-r1:2::gentoo] USE="cups introspection (-aqua) -examples -test -vim-syntax -xinerama" ABI_X86="32 (64) (-x32)" 0 KiB [ebuild U #] media-gfx/gnome-screenshot-3.34.0::gnome-next [3.32.0::gentoo] 225 KiB [ebuild N ] gui-libs/tepl-4.2.1:4::gentoo USE="introspection -test" 454 KiB [ebuild U #] gnome-extra/gnome-calculator-3.35.2::gnome-next [3.32.2::gentoo] 955 KiB [ebuild U #] media-gfx/eog-3.35.3:1::gnome-next [3.32.2:1::gentoo] USE="exif introspection jpeg lcms svg tiff -debug% -xmp (-gtk-doc%)" 3,554 KiB [ebuild U #] net-libs/gnome-online-accounts-3.35.90:0/1::gnome-next [3.32.1:0/1::gentoo] USE="gnome introspection vala -debug -kerberos" 839 KiB [ebuild rR ] gnome-base/gnome-control-center-3.32.2:2::gentoo USE="bluetooth cups gnome-online-accounts ibus networkmanager systemd -debug (-elogind) -flickr -kerberos -test -v4l -wayland" INPUT_DEVICES="-wacom" 0 KiB [ebuild U #] app-editors/gedit-3.35.1-r2::gnome-next [3.34.1::gentoo] USE="introspection python spell vala -gtk-doc" PYTHON_SINGLE_TARGET="python3_6 -python3_7 -python3_8" 14,451 KiB Total: 15 packages (9 upgrades, 4 new, 2 reinstalls), Size of downloads: 20,477 KiB The following packages are causing rebuilds: (gnome-base/libgtop-2.40.0:2/10::gnome-next, ebuild scheduled for merge) causes rebuilds for: (gnome-extra/gnome-system-monitor-3.32.1:0/0::gentoo, ebuild scheduled for merge) (gnome-base/gnome-control-center-3.32.2:2/2::gentoo, ebuild scheduled for merge) Would you like to merge these packages? [Yes/No]
(In reply to Andreas Sturmlechner from comment #1) > It's an overlay bug, not a Portage bug. Isn't stuff in /etc/portage the highest priority? I mean, you can even override profile masks there, why would an overlay be allowed to override it?
Another poll: https://forums.gentoo.org/viewtopic-t-1172790.html
(In reply to Enne Eziarc from comment #3) > Lua overlay also causes problems in the same way. > > > (In reply to Andreas Sturmlechner from comment #1) > > It's an overlay bug, not a Portage bug. > > If this is an “overlay bug” then the portage(5) manpage should stop > advertising it as a feature, and QA checks should be catching it. Why aren't > they? As an overlay maintainer, I assumed I had to use package.unmask when I imported a masked package from ::gentoo and wanted it not to be p.masked in my repo. It looks like the Lua repo is doing the same thing. Digging a little deeper now, it seems I can add a negative "-cat/pkg" to profiles/p.mask instead of using p.unmask, and this works as expected (not overriding /etc/portage/p.mask). Is this what we should be doing instead? I agree that it would be nice if /etc/portage/package.mask took precedence over all repos.
