gnome-next overlay overwriting package.mask

[Massimo-B]

Cloned from https://bugs.gentoo.org/624864

https://github.com/Heather/gentoo-gnome/blob/master/profiles/package.unmask

This file is defining its own unmasks for the repo.
This is the 1st issue of this ticket. Isn't that a bad style having repos unmasking or accepting their own elements?

The 2nd issue of this ticket is that I wondered that any
/etc/portage/package.mask/*
with */*::gnome-next is just ignored. I set this line for every inoccifial overlay for not updating implicitly version packages from the overlay. This seems more like a portage bug, that overlay profiles have precedence over /etc/portage/ .
If so I would split this 2nd issue into a separate bug report.

[Cynede]

@Massimo-B

1. I don't see how this is overlay issue and what else would you suggest? I think it's possible to change masking for testing process in main tree but it should be discussed with gnome team and it's not related to this overlay, if you think different - I'm for sure will be glad to support another solution.

2. Yes, some of things are complicated there even for overlay when I want to mask something the only way I can do it currently is by removing keywords, if I want to mask something locally it's very tricky, there were actually some hacks when I needed that but I already forgot them, if I will dig this out I will let you know.

[Massimo-B]

It's been a while I had these issues, I need to figure out the details again. But as for */*::gnome-next which I do with all overlays, shouldn't this always work as first precedence? If not, then this is a Portage bug.
I usually do that with all overlays because adding full stuffed overlays tend to replace a list of official packages they overwrite, even if I just need a single package of that overlay.

[Cynede]

@Massimo-B well it's possibly because package.unmask unmasks it...
just in case of interest - what single package / set of packages do you need?

[MalcolmMielle]

I'm hit with this issue when trying to not emerge latexila from this overlay. even by adding it to a unmask file, it's still gets updated.

See here for the gentoo forum discussion that lead me to this issue.

[Cynede]

@MalcolmMielle read my first answer to that issue, it's not the problem of this overlay, gnome team is pushing untested broken crap to tree and mask it there (that's why we need to unmask it in this overlay) but maybe we can unmask only ::gnome-next packages... in your case you can remove keywords from ebuild and contribute that change, possibly provide previously working version.

Thank you

[nick87720z]

@mpkh to make overlay masking/unmasking only own packages, untouching other together portage tree, is not it better to just postfix all entries with ::gnome-next? Should work at least until portage begins to treat overlay's profile settings as local.

[Massimo-B]

I did not follow this issue anymore, not sure which package was pointing me to this.

The 2nd issue of this ticket is that I wondered that any
/etc/portage/package.mask/*
with /::gnome-next is just ignored. I set this line for every inoccifial overlay for not updating implicitly version packages from the overlay. This seems more like a portage bug, that overlay profiles have precedence over /etc/portage/ .

However this behaviour still seems wrong and my local package.mask should always have precedence.

[Cynede]

@nick87720z not sure if that is possible, we can try

[reanimus]

This hasn't been updated in a bit, but I'd think it makes more sense to unmask only this repo's stuff. I have something along this lines set up for repos I only want one or two ebuilds out of. In my /etc/portage/package.mask, I have */*::repo and for each package I want to unmask, I have category/package::repo. If the goal is to unmask the packages in this repo, that should work.

[Cynede]

feel free to PR the change

[reanimus]

Just gave it a spin with a fork... It looks like portage actually doesn't allow you to scope it to repos in the profile/package.unmask? Not sure why :(