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 1KkOn6-0004a6-6k for garchives@archives.gentoo.org; Mon, 29 Sep 2008 19:52:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D120AE0522; Mon, 29 Sep 2008 19:52:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id AB37FE0522 for ; Mon, 29 Sep 2008 19:52:19 +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 49A6E64CE1; Mon, 29 Sep 2008 19:52:18 +0000 (UTC) Message-ID: <48E131E3.80103@gentoo.org> Date: Mon, 29 Sep 2008 12:52: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 CC: jmbsvicetto@gentoo.org Subject: Re: [gentoo-dev] [RFC] PROPERTIES=set for meta-packages that should behave like package sets References: <48DECDFE.7010606@gentoo.org> <20080929000257.7bfd0905@snowmobile> <48E0151F.1020404@gentoo.org> <200809291713.30783.bo.andresen@zlin.dk> In-Reply-To: <200809291713.30783.bo.andresen@zlin.dk> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 36520c4e-a9ae-45db-9dc4-1a1fee6c537c X-Archives-Hash: f0c6b1f3a047fc83ef237e0304af6697 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bo =C3=98rsted Andresen wrote: > On Monday 29 September 2008 01:37:03 Zac Medico wrote: >>> Why the need for multiple solutions at all? PROPERTIES=3Dset is too w= eird >>> and involves too much nonsensical behaviour to be useful. >> I don't see the PROPERTIES=3Dset 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 >=20 > I really don't see the advantages of fitting 'into the existing ebuild=20 > framework like virtual ebuilds do'. Can you name any real advantages to= it?=20 This idea initially came up when Jorge (jmbsvicetto) mentioned that he had used a package set to replace a meta-ebuild in the desktop-effects overlay, and then users complained that the set did not supporting the USE conditionals that the previous meta-ebuild had supported. Perhaps we can support USE conditionals in sets, but this also seems to mean that we will need a package.use analog that applies to package sets. Assuming that we'll need a package.use analog, we might view the act of replacing meta-packages with sets as a sort of "throwing the baby out with the bath water" scenario in sense that meta-packages have lots of useful features and the only reason to migrate them to sets would be take advantage of the unique features which sets have to offer. So, rather than force a complete migration, we may want to consider integrating meta-packages into the sets framework. > Having virtuals as ebuilds makes sense because ebuilds need to depend u= pon=20 > them. But I can see no decent use case for letting a non-set ebuild dep= end=20 > upon a set. As far as I'm concerned sets are merely a convenience for u= sers.=20 > It allows them to install, reinstall (mostly of interest for scm ebuild= s),=20 > keyword, unmask, set use flags for or uninstall a set of packages. The "set use flags" part is interesting. If that's the case, it seems somewhat ambiguous to use sets to "set use flags" and also allow sets to contain USE conditionals. Supposing that we do allow both, are we going to create some analog of package.use for sets, or not? If we do create such an analog, how would it apply to nested sets? Should nested sets be able to have separate USE conditional settings from the sets that nest them? - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjhMeIACgkQ/ejvha5XGaN5EgCgp/KWDienRceXkzV5GX4u9wZp oYEAnRZ7Z8BErZGRNe6muf7fPRLlW/bQ =3DRFAJ -----END PGP SIGNATURE-----