From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 6626713877A for ; Sun, 29 Jun 2014 12:36:42 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8EB7FE08FB; Sun, 29 Jun 2014 12:36:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BB4EAE08C5 for ; Sun, 29 Jun 2014 12:36:36 +0000 (UTC) Received: from 127.0.0.1 (bolobolo1.torservers.net [96.47.226.20]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: hasufell) by smtp.gentoo.org (Postfix) with ESMTPSA id 232C9340249 for ; Sun, 29 Jun 2014 12:36:34 +0000 (UTC) Message-ID: <53B0084D.1080107@gentoo.org> Date: Sun, 29 Jun 2014 12:36:29 +0000 From: hasufell Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Docker 1.0.0 masked for no known reason? References: <20140629025822.GB22414@kroah.com> <20140629051736.0173fd6b@marga.jer-c2.orkz.net> <20140629034608.GA26508@kroah.com> <53AFFA20.1060107@gentoo.org> <53B00293.8080201@gentoo.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: fb249e5f-2a6e-4df6-b7a0-1e90c7d20753 X-Archives-Hash: 0d3203b01e4fdfe939071503b2b3f9a9 Rich Freeman: > On Sun, Jun 29, 2014 at 8:12 AM, hasufell 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.