Re: [gentoo-dev] New Portage fork: sys-apps/portage-mgorny

[Georgy Yakovlev <ya@sysdump.net>]

On Fri, 2018-03-23 at 16:23 +0000, Patrick Steinhardt wrote:
> This wouldn't help the maintainers of overlays, though, and puts
> the burden on the user. One scenario where masks maintained in
> overlays would be useful is the musl overlay, which carries
> patches to various packages to have them compile with musl libc.
> Obviously, I always want to use packages provided by the musl
> overlay in case the same package from the Gentoo tree has build
> failures. Even if the Gentoo-provided package gets updated, I'll
> still want to use the older version from the musl tree, as the
> build errors are likely to still exist.
> 
> If overlays were able to ignore packages from other repositories,
> the musl overlay could simply mask out packages from the Gentoo
> repository which are known to not compile on musl-based systems.
> Like this, the user does not have to maintain these masks
> manually, but they are already managed at a central place and
> updated with the musl repository.
> 
> Patrick

It's currently possible to do with a sort-of-automated script in 
/etc/portage/repo.postsync.d

i asked[1] ::musl about that and they do not want that.

the script provided the issue is just an example, it should check which
repo was just synced, also it does not care about versions, it just
masks the versionless atom, there are no any sanity checks.
it's just proof of concept.

But I find it useful on my underpowered APU system which runs musl.
I just want to avoid build failures, as each build takes a LOT of time.
I would not run that on a workstation, I'd better bump instead and port
the patches/ebuilds.
running ::musl is an active commitment, and it often requires
intervention and those should be contributed back if possible.


[1]https://github.com/gentoo/musl/issues/110

-- 
Georgy