On Fri, 2020-08-14 at 23:12 +0200, Michał Górny wrote: > On Fri, 2020-08-14 at 15:42 +0000, Joakim Tjernlund wrote: > > On Fri, 2020-08-14 at 17:31 +0200, Ulrich Mueller wrote: > > > > > > > > On Fri, 14 Aug 2020, Joakim Tjernlund wrote: > > > > When pkgs are masked in the profile, it affects all variants of that > > > > pkgs, even the ones that are in other overlays. > > > > Example: > > > > !!! The following installed packages are masked: > > > > - sys-auth/sssd-9999::transmode (masked by: package.mask) > > > > /usr/portage/profiles/package.mask: > > > > # Matt Turner <matts...@gentoo.org> (2020-08-13) > > > > # Masked for testing > > > > My sssd-9999 is now masked. > > > > Could the profile syntax be extended to include syntax allowed in > > > > /etc/portage ? Then one could use the ::gentoo syntax (or so I hope) > > > > > > The :: syntax is Portage specific and doesn't exist in EAPI 7. > > > So there's no chance to get it into the profile dir anytime soon > > > (because that would imply :: to be added to a future EAPI and the > > > top-level profile dir to be bumped to that EAPI). > > > > Is profile part of EAPI? masks are not defined/used in ebuilds directly. > > > > > You could override the mask in your overlay's profile/package.mask > > > instead, using an entry with the "-" operator. > > > > Yes, I know I can add that in profile/package.mask but I am looking for the > > bigger > > picture here. This has to stop somehow, there need to be something that > > limits > > the mask scope to the repo/overlay it is defined. > > > > Why is that? I dare say the bigger picture needs to include different > mask reasons. Sure, 'masked for testing' may or may not make little > sense for live ebuilds. However, 'masked for security issues' may > pretty apply to custom repo ebuilds as well. >
Possibly, but the way you mask Test/Security should then be referring to specific versions, not all possible versions in the universe. Jocke