Re: [gentoo-portage-dev] profile masking

[Michał Górny]

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 <mattst88@g.o> (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.

-- 
Best regards,
Michał Górny