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 1KkX9o-0004BZ-GZ for garchives@archives.gentoo.org; Tue, 30 Sep 2008 04:48:20 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6A775E0158; Tue, 30 Sep 2008 04:48:19 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 190B6E0158 for ; Tue, 30 Sep 2008 04:48:19 +0000 (UTC) Received: from [172.28.2.137] (bl5-82-139.dsl.telepac.pt [82.154.82.139]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 6D8B064DDE for ; Tue, 30 Sep 2008 04:48:11 +0000 (UTC) Message-ID: <48E1AF7B.4020800@gentoo.org> Date: Tue, 30 Sep 2008 04:47:55 +0000 From: "Jorge Manuel B. S. Vicetto" User-Agent: Thunderbird 2.0.0.16 (X11/20080727) 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> <20080929000257.7bfd0905@snowmobile> <48E0151F.1020404@gentoo.org> <200809291713.30783.bo.andresen@zlin.dk> <48E131E3.80103@gentoo.org> In-Reply-To: <48E131E3.80103@gentoo.org> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 2f317789-9329-4c44-bbec-273d18038e1a X-Archives-Hash: 299223040f8c7e171b1e02134dc01f90 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zac Medico wrote: > 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 = weird >>>> 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 >> 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 t= o it?=20 >=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. For those interested, the complaints were about this meta-ebuild http://git.overlays.gentoo.org/gitweb/?p=3Dproj/desktop-effects.git;a=3Db= lob;f=3Dx11-wm/compiz-fusion/compiz-fusion-0.7.8.ebuild;h=3D91783ea46143d= aa90f8102936e170ff43059491b;hb=3Dmaster that I replaced with the http://git.overlays.gentoo.org/gitweb/?p=3Dproj/desktop-effects.git;a=3Db= lob;f=3Dsets/compiz-fusion-complete;h=3D5281e30f5a4677f5f0ef882db9ff18788= 3d569ea;hb=3Dmaster and http://git.overlays.gentoo.org/gitweb/?p=3Dproj/desktop-effects.git;a=3Db= lob;f=3Dsets/compiz-fusion;h=3D8a7869e77ea72f54f9bea6e1b214c124c7025934;h= b=3Dmaster sets. Optional deps on the set would allow the user to select whether to install the gnome or kde backends and to install the unsupported plugins or not. Another alternative in this case, is to use the set operators so that I have a single set for all packages and tell the user to create a set with the packages he doesn't want to install from the overlay and run emerge @compiz-fusion-@compiz-fusion-unwanted. > 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. Can package.use syntax be extended to allow set entries? @compiz-fusion -gnome kde kde4 - -- Regards, Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org Gentoo- forums / Userrel / Devrel / SPARC / KDE -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjhr3sACgkQcAWygvVEyAIs7QCfVZUPK5tV3PxTRPDz18C97Y1d xFQAn2qNMzPyDUhr0RJDsoWg45MWkJEJ =3DTYZC -----END PGP SIGNATURE-----