From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LeBJQ-0003xo-9B for garchives@archives.gentoo.org; Mon, 02 Mar 2009 16:48:16 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 576AEE03CA; Mon, 2 Mar 2009 16:48:15 +0000 (UTC) Received: from yx-out-1718.google.com (yx-out-1718.google.com [74.125.44.157]) by pigeon.gentoo.org (Postfix) with ESMTP id 32298E03CA for ; Mon, 2 Mar 2009 16:48:15 +0000 (UTC) Received: by yx-out-1718.google.com with SMTP id 3so1458855yxi.46 for ; Mon, 02 Mar 2009 08:48:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:subject :message-id:in-reply-to:references:x-mailer:mime-version :content-type; bh=p6LrGS639pcrgJUWJllWoxIoj+K39QG+HGoaSUox/wk=; b=c6+qYrQ+HAQFGqd9gH0kpj72WrcaUpzbPpC087McnCykvYFAVBdto3jTTj47zdfdx+ Ve8JVcDCXKKODr9dtTFrlrkmoTjnSF8iBNOvBXIWg0Yr2eqhXmw4FYIj5lkLXBN+Zer7 TkBnG8ndHI7cJfGRk2u5/jqZKWlyP/q03ysrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:subject:message-id:in-reply-to:references:x-mailer :mime-version:content-type; b=xzXH+pOxL+az98Mn62HkeG53ekpvyvupXwl0aGJaMGNgzUm6uCXIuWTq25SltQbr28 QGVz61lItlQJtKTRceuGz6SBBelo95f8NIVphWQoxUonDAt0JjC2lN5Fndt4M8ZFR2E1 ZTJWfvtH71/FCwNuU1ki32DWVQxwMb1PfB/Hk= Received: by 10.101.67.11 with SMTP id u11mr1071556ank.145.1236012494344; Mon, 02 Mar 2009 08:48:14 -0800 (PST) Received: from snowcone (92-235-187-79.cable.ubr18.sgyl.blueyonder.co.uk [92.235.187.79]) by mx.google.com with ESMTPS id c5sm671405nfi.28.2009.03.02.08.48.13 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 02 Mar 2009 08:48:13 -0800 (PST) Date: Mon, 2 Mar 2009 16:48:07 +0000 From: Ciaran McCreesh To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Repository stacking and complementary overlays Message-ID: <20090302164807.6324266c@snowcone> In-Reply-To: <1235702483.8324.38.camel@localhost> References: <1235702483.8324.38.camel@localhost> X-Mailer: Claws Mail 3.7.0 (GTK+ 2.14.7; x86_64-pc-linux-gnu) 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 Content-Type: multipart/signed; boundary="Sig_/tr5x6qX6mdxfIGY4LCbTH=S"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-Archives-Salt: e2d5d1c5-0ced-4ece-9200-092a03d6d10d X-Archives-Hash: f7c8ce05e63b9249749dcb975de5c78c --Sig_/tr5x6qX6mdxfIGY4LCbTH=S Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 27 Feb 2009 04:41:23 +0200 Mart Raudsepp wrote: > So here the reverting of a masking in gentoo-x86 is quite intentional > and currently desired. This is fundamentally broken as a concept. Adding an overlay should not have any impact upon other repositories. It should be possible for a user to add an overlay, and make limited use of that repository, without having to worry that the mere act of adding that overlay will make massive changes to what's visible in other repositories. Overlays shouldn't be altering the visibility of things outside of that overlay without explicit user action. > By this snippet we could simply move the current relevant maskings > from profiles/package.mask to profiles/base/package.mask and call it > a day (and screw over the few profiles that don't end up parenting > base/), as QA forced us to do in case of per-arch mask negations in > gentoo-x86 a while back. > But it doesn't seem to be as simple as that. Well no, because profiles/base/ in your overlay is entirely unrelated to profiles/base/ in the master. > > Only reason it flies for portage is because it collapses it all > > into one stack; for managers designed to support multiple > > standalone repos that assumption no longer applies, thus that > > behaviour (outside of PMS) breaks. >=20 > Last I knew the official council approved PMS was meant to describe > portage behaviour at the time, which appears to have been the same > along the way - treating all overlays in the same "stack" as PORTDIR, > perhaps as there is no means to declare a different "stack". PMS does not attempt to document Portage behaviour in the cases where Portage behaviour is dumb. That's the reason there's as little as possible mentioned regarding overlays there -- Portage's overlay model is a horrible hack, and forcing package managers to implement it rather than offering a true multiple repository model would be a serious hit on usability. The way forward here is to identify what you're trying to achieve, whilst ignoring how things are currently defined or what is or is not possible. Then we can look at that and work out whether it can be mapped to an existing solution or some easily-implementable new solution. Starting with implementation is the wrong approach. --=20 Ciaran McCreesh --Sig_/tr5x6qX6mdxfIGY4LCbTH=S Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmsDckACgkQ96zL6DUtXhGvzwCgyAzb0dZljeipyUxeQMQrRkc8 PUcAnR/+YMJAO4zueiLuYBoH6t7J6jIY =Pi4E -----END PGP SIGNATURE----- --Sig_/tr5x6qX6mdxfIGY4LCbTH=S--