Re: profile masking

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 <[email protected]> (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