Summary: | portage does not seem to respect package.mask in overlays | ||
---|---|---|---|
Product: | Portage Development | Reporter: | William L. Thomson Jr. <wlt-ml> |
Component: | Core | Assignee: | Portage team <dev-portage> |
Status: | UNCONFIRMED --- | ||
Severity: | normal | CC: | bog, sandino |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=737148 https://bugs.gentoo.org/show_bug.cgi?id=832962 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
William L. Thomson Jr.
2017-12-14 18:02:55 UTC
profiles/package.mask is special in that it isn't really a "profile" config file, but rather a repo config file. It only affects ebuilds in that repo, and repos that declare it as a "master". In other words, your repo inherits masks from "gentoo" since it has "masters = gentoo". gentoo does NOT have "masters = os-xtoo", so it does not inherit masks. The other issue probably warrants a separate bug/feature request. If you put your masks in profiles/linux/amd64/package.mask, I think they will work more as you expect: they should affect all packages in all repos, assuming the system has make.profile pointed to the right place. Ok but I need to mask for any overlay users. Not just those using my custom profiles. Which I do not expect anyone other than myself to use my profiles. But there will be problems with mixing tree packages with my overlay, just dev-java/*. I have a greater need really for more dev-java/*::gentoo, the individual is more a stop gap on ones I know cause issues. Not sure about reversing masters, but I guess there is no way for an overlay to mask a tree category. I can file another bug on that, but seems same issue. If its not respected, then I would have to put that in an profile mask file vs global for the repo. It seems odd as package.unmask works as expected. If something is masked in tree, I can unmask that with package.unmask. Seems like I should be able to mask just the same. I guess that works because those packages are in my overlay. (In reply to William L. Thomson Jr. from comment #3) > It seems odd as package.unmask works as expected. If something is masked in > tree, I can unmask that with package.unmask. Seems like I should be able to > mask just the same. I guess that works because those packages are in my > overlay. Right, I believe the profiles/package.unmask file only unmasks packages that exist in your repo. I think it uses the same logic as profiles/package.mask. Personally, I think the current behavior is reasonable, and should not be changed without some additional config setting. Allowing random overlays to affect packages that are visible in the gentoo repo seems like a bad idea in general. (In reply to Mike Gilbert from comment #4) > > Right, I believe the profiles/package.unmask file only unmasks packages that > exist in your repo. I think it uses the same logic as profiles/package.mask. Confirmed with a random package not in my overlay. Adding it to package.unmask, did not unmask it. Since it was not in my overlay. > Personally, I think the current behavior is reasonable, and should not be > changed without some additional config setting. Allowing random overlays to > affect packages that are visible in the gentoo repo seems like a bad idea in > general. Well they are already choosing to use an overlay. If the overlay knows there will be problems with packages in tree. There should be some means there. It will only cause issues that would not exist otherwise. More so when what is in tree is outdated old, does not work with newer, etc. Most overlays, but not all, do tend to have improvements over the tree. I tend to read and see that a fair amount. Either way its Gentoo so such options should exist right? A person is already choosing to use an overlay. Seems excessive for an overlay to have to tall all users, go mask this or that. As it cannot be done globally. Forcing someone to use an overlay profile for masks. Seems of much more concern than adding an overlay that masks a category. Not to mention additional instructions to make the overlay usable. It should be add overlay and merge. Not add overlay, mask category, switch profile, etc for all user of said overlay. Even if well documented, many will not read and just add overlay, merge stuff, and report issues. I do not see any overlay masking a category without a really good reason. Very likely the overlay developer/maintainer has a better clue than any user of said overlay. Thus should be able to prevent issues and make things easier for users. (In reply to Mike Gilbert from comment #1) > profiles/package.mask is special in that it isn't really a "profile" config > file, but rather a repo config file. It only affects ebuilds in that repo, > and repos that declare it as a "master". > > In other words, your repo inherits masks from "gentoo" since it has "masters > = gentoo". gentoo does NOT have "masters = os-xtoo", so it does not inherit > masks. Would you be open to documenting that this is the case in portage(5), or perhaps I can submit a patch? I came here wondering why "::repo" was causing a syntax error when I tried to add it to my overlay's package.mask. Patches to improve documentation are always welcome. |