Re: [gentoo-dev] musl, sbcl, and ros

[Alec Warner]

On Fri, Dec 2, 2022 at 11:28 AM Peter Stuge <peter@×××××.se> wrote:
>
> Andrey Grozin wrote:
> > This means that no user of the musl profiles has ever been able to emerge
> > all these packages (because they did not have sbcl). And all these
> > packages should be pmasked in the musl profiles.
>
> Is the last sentence actually true?
>
> Shouldn't only ebuilds with actual problems be masked?
>
> Even if there's currently no possibility to emerge other packages
> which depend on that it seems incorrect to mask those other packages
> only because a dependency can't be emerged?
>
> I don't think portage cares; it will show sbcl masked if it is a
> dependency, right?

The project has a (somewhat implicit) goal to prefer installable
depgraphs. We use software like pkgcheck to verify these (and there
are CI failures if the depgraph is broken, and we make developers fix
such things.)

So if we had like, A -> B -> C, and C is profile-masked on some
profile, we should be masking A and B (so we avoid users seeing a
broken depgraph.)
You might think "well I see A -> B[foo] all the time, and portage will
make me set USE=foo on B." This is generally true except:
 - Oftentimes if this is a sane default, B will have USE="+foo" (e.g.
foo will be on by default) and this requirement will not be visible to
users.
 - USE flags are intended to be toggled and most USE flag values are
supported by Gentoo (except for REQUIRED_USE restrictions.)
 - Portage has an autounmask flag that will configure things so B is
installable (by flipping foo on for you); but this function does not
exist for profile-masks.

We do not expect users to "undo" profile-masks, so when things are
profile-masked we value the user experience (if X is visible, X should
be installable) rather than minimal masking.

-A

>
>
> Thanks
>
> //Peter
>