On Fri, Dec 2, 2022 at 11:28 AM Peter Stuge <[email protected]> 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 >
