Rich Freeman: > On Sun, Jun 29, 2014 at 8:12 AM, hasufell <hasuf...@gentoo.org> wrote: >> Also, those masks are rarely short-term in practice, because well, see >> this thread. > > Is there any evidence to support this statement? You only notice > masks when they're a problem, and these kinds of masks tend to be a > problem only if they're long-term. >
Yeah, I'v been collecting and analyzing data over the years to come up with the results just now ;) I was just giving my own perception of things. >> Developer overlays are widely used. So yes, ~arch users will be testing >> it, probably even arch users. It also limits the potential damage for >> the user, because he can very easily toss out the crap by just >> removing/masking the whole overlay instead of going on adventure reading >> broken portage output. >> > > If I want three users following a bug to test something, it is far > easier to tell them to just unmask it than to tell them to go install > my developer overlay. Also, right now you can't easily pull in just > one package from an overlay, so they get the benefit of installing > whatever else is in my overlay. > 'layman -a overlay && flaggie foo +~amd64 && emerge -av1 foo' can be easier than figuring out masks that maybe even go across multiple dependencies (need to remind anyone of multilib masks and how screwed anyone was/is who mixes only a few ~arch packages with arch?). Also, pulling in just one package from an overlay is almost the same as unmasking a tree ebuild. > And as I stated previously creating an overlay for one package is > unnecessary work. > For single packages, you use your developer overlay. For more complex things like multilib, you create a separate one. > I'm not saying that we should be leaving stuff in the tree for six > months for "testing" - just that there are cases where it can be > convenient to have a short-term mask. This is still too vague for me. If it's expected to be short-term, then it can as well just land in ~arch. If it's not expected to be short-term, then I cannot follow the argument.
