On 01/06/2017 12:46 PM, William L. Thomson Jr. wrote: > On Friday, January 6, 2017 9:14:54 AM EST Alec Warner wrote: >> >> The nice thing about ::graveyard or similar is that its a clear demarcation >> between maintained (in tree) and unmaintained (graveyard.) It also means >> that people doing actual maintenance work can basically ignore the >> graveyard as a matter of policy. The ebuilds are archived there (for users) >> but since they are unmaintained they may not work correctly. > > This is what the Java team used to do. There was a java-graveyard-overlay. I > do not believe any package ever moved there came back into the tree. It did > result in a pretty messed up overlay, but makes it a user problem. > > At the same time, something could always be restored from VC. Not like > removal > is removing all history and traces. Thus not sure such overlay is really even > beneficial. Using it could cause lots of problems if they just care about 1 > package or a few. >
There's a nice trick around that, actually: let's assume the overlay is
called "foo-overlay".
In package.mask:
*/*::foo-overlay
will mask all packages in the overlay. You can then add packages to
package.unmask:
pkg-cat/foobar::foo-overlay
That should alleviate most issues, though it can make dependencies a
PITA if those deps are also in the overlay. In that case, emerge should
yell at you and suggest adding lines to package.unmask.
--
Daniel Campbell - Gentoo Developer
OpenPGP Key: 0x1EA055D6 @ hkp://keys.gnupg.net
fpr: AE03 9064 AE00 053C 270C 1DE4 6F7A 9091 1EA0 55D6
signature.asc
Description: OpenPGP digital signature
