I think it makes sense to be able to mask and unmask packages in the following scopes: - a portage tree (/usr/portage/profiles and ${PORTDIR_OVERLAY}/profiles) - a profile (/etc/make.profile or the profile dir, etc.) - a machine (/etc/portage) Clearly, /etc/portage is working nicely. The other two are not consistent. You can mask packages in /usr/portage/profiles, but not in ${PORTDIR_OVERLAY}/profiles. Furthermore, I think it makes sense to have this ability within a particular profile directory; this cannot be done at all currently. If you think this is a bad idea, please let me know why. I am interested in comments. Also, if this is not a trivial change, I will attempt to make a patch and submit it (let me know). Thanks!
You can already mask stuff in /etc/make.profile/packages (the semantics there is different than in package.mask though).
That's true, but it creates a problem. There is no way to unmask packages in profiles/packages, so do we create profiles/package.unmask ? That makes things confusing. Or do we come up with a whole other spec for unmasking packages for profiles/packages. What's the right way to do this? I think working towards consistency is the way to go.
Why would you need to unmask things in a profile? Personally I don't like the current profile stuff much as it has to many limitations, but I don't have the time (and won't have for a while) at the moment to redesign it.
If you are maintaining a portage overlay profile, it's a nice way to push unmasks to a number of servers without having to maintain your own complete tree.
If you can point me in the right stylistic, theoretical direction, I will be glad to write/submit the patch.
Makes sense for overlays, but this has the potential to cause a lot of problems. There is no way to restrict unmasks to a particular tree and this would end up unmasking things in the portage tree. You would have no control over devs creating new packages that override your changes. package.mask is intended for severe brokeness and extended controlled testing.
I don't know if this should be a new bug or not... but the portage package should create a blank or template unmask file, so one can find it by a locate or find. background: I kept looking and looking for an unmask file.. There was none! I had to create it! (and know where to create it!) which wasn't standard which blew me away.. I don't even know where it is right now! I'd include that in this comment... but that would require a search for it!.. heck I'll search for it.. bash-2.05b$ find /usr -iname '*.unmask' bash-2.05b$ find /etc/ -iname '*.unmask' find: /etc/cups/certs: Permission denied find: /etc/cdbkup: Permission denied find: /etc/samba/private: Permission denied find: /etc/webmin: Permission denied find: /etc/lvm/archive: Permission denied find: /etc/lvm/backup: Permission denied /etc/portage/package.unmask bash-2.05b$ There it is!! I think I might have even needed to create the portage dir... anyway... if the make.conf was in portage dir too that would be nice.. or maybe have it all in make.conf.d
people have requested template .unmask and .mask files before the answer has been no read the documentation (portage(5))
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
This has been fixed with the introduction of cascaded profiles.
