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 1Kk5pK-0004G0-He for garchives@archives.gentoo.org; Sun, 28 Sep 2008 23:37:22 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id BCE9BE04D3; Sun, 28 Sep 2008 23:37:21 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 90891E04D3 for ; Sun, 28 Sep 2008 23:37:21 +0000 (UTC) Received: from [192.168.22.10] (ip68-4-152-120.oc.oc.cox.net [68.4.152.120]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 5DC0264BF3 for ; Sun, 28 Sep 2008 23:37:20 +0000 (UTC) Message-ID: <48E0151F.1020404@gentoo.org> Date: Sun, 28 Sep 2008 16:37:03 -0700 From: Zac Medico User-Agent: Thunderbird 2.0.0.17 (X11/20080914) 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] [RFC] PROPERTIES=set for meta-packages that should behave like package sets References: <48DECDFE.7010606@gentoo.org> <20080928213219.66a30341@snowmobile> <48DFEEB8.5040608@gentoo.org> <20080928220151.33656aca@snowmobile> <48E0011E.7040808@gentoo.org> <20080928232853.6540b31d@snowmobile> <48E00B9B.3060600@gentoo.org> <20080929000257.7bfd0905@snowmobile> In-Reply-To: <20080929000257.7bfd0905@snowmobile> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 3a33c98c-16ca-4871-a08f-71d4c323f1fd X-Archives-Hash: 1c9971596ec40244e2b8c91bded03be2 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ciaran McCreesh wrote: > On Sun, 28 Sep 2008 15:56:27 -0700 > Zac Medico wrote: >> As I've tried to explain, the an ebuild which exhibits >> PROPERTIES=set doesn't necessarily have to behave any differently >> than a meta-package currently does. What we would do is create a >> configuration that maps the set-property ebuild into set space. For >> example, `emerge kde-meta` would behave as as normal meta-package >> currently does, and `emerge @kde-meta` would reference the same >> package as a set and could thereby trigger different behavior which >> is appropriate for a set. > > ...and what would that behaviour be? What does a PDEPEND mean for a > set? Like virtuals, it makes sense to restrict the dependencies to the RDEPEND variable as mentioned in glep 37 [1]. I should have mentioned this earlier since it might not be obvious to some. >>> Here's an alternate proposal: Repositories can ship sets via files >>> in sets/*.conf. The format is as described in [1]. In configuration >>> files, operations applied to a set are applied to anything matching >>> any spec listed in that set (or any set that set contains, and so >>> on). On the command line, sets and non-sets cannot be mixed, and >>> multiple sets cannot be specified. >>> >>> [1]: http://paludis.pioto.org/configuration/sets.html >>> >> Perhaps can use something like you've got there in addition to the >> PROPERTIES=set approach. > > Why the need for multiple solutions at all? PROPERTIES=set is too weird > and involves too much nonsensical behaviour to be useful. I don't see the PROPERTIES=set approach as being worse than any other approach for package set definition. It has lots of advantages because of the way that it fits into the existing ebuild framework like virtual ebuilds do [1], allowing it to leverage all of the existing features of the framework (including package.use) and also allowing it to leverage the tools that have been designed to work with the framework. [1] http://www.gentoo.org/proj/en/glep/glep-0037.html - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjgFR4ACgkQ/ejvha5XGaNA5ACfUkefckOusoqkcSFgllZ6gSXu AP0AoNA4e/r5VxPtdDZtQRTzWDWZIa0U =GhAY -----END PGP SIGNATURE-----