I usually mask entire overlays with */*::overlay than unmask whatever I need. But things break when overlays have own package.unmask. Problem is that portage handles masks, unmasks, etc from all attached repos (including settings) in one step, thus package, unmasked by overlay, is impossible to be masked.
One more confuse happens when looking this package in eix, which doesn't (yet) interpret profile data from repos, thus showing them as masked. E.g. I have calculate overlay (using their distro), which has many python2-only packages too, necessary for their utils.
Would prefer them to avoid unpredictable problems, with other distro it would be not problem besides confusion looking it in eix.
I understand, but the main use case is simply adding the overlay and then installing packages from it, which would fail for those masked in the main tree.
I usually mask entire overlays with
*/*::overlay
than unmask whatever I need. But things break when overlays have own package.unmask. Problem is that portage handles masks, unmasks, etc from all attached repos (including settings) in one step, thus package, unmasked by overlay, is impossible to be masked.One more confuse happens when looking this package in eix, which doesn't (yet) interpret profile data from repos, thus showing them as masked. E.g. I have calculate overlay (using their distro), which has many python2-only packages too, necessary for their utils.
Would prefer them to avoid unpredictable problems, with other distro it would be not problem besides confusion looking it in eix.