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 1KYCUc-0002o1-I0 for garchives@archives.gentoo.org; Wed, 27 Aug 2008 04:18:51 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 49B9DE044F; Wed, 27 Aug 2008 04:18:49 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 23DC0E044F for ; Wed, 27 Aug 2008 04:18:49 +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 29A7466184 for ; Wed, 27 Aug 2008 04:18:48 +0000 (UTC) Message-ID: <48B4D5AD.4070407@gentoo.org> Date: Tue, 26 Aug 2008 21:18:53 -0700 From: Zac Medico User-Agent: Thunderbird 2.0.0.16 (X11/20080707) 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] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition) References: <48B1CC3C.2000103@gentoo.org> <20080825201217.194fecad@googlemail.com> <48B309C2.1060204@gentoo.org> <200808252103.27006.levertond@googlemail.com> <20080826142044.28367055@googlemail.com> <48B440F6.7020705@gentoo.org> <48B4B298.5030005@gentoo.org> <20080826202309.2e328a27@gentoo.org> <48B4C714.2020209@gentoo.org> In-Reply-To: <48B4C714.2020209@gentoo.org> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 97ae16bf-9772-4fe6-8b77-dfd240980b56 X-Archives-Hash: 4034cc16f202410f7015d199c242bd1e -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Zac Medico wrote: > Michal Kurgan wrote: >> On Tue, 26 Aug 2008 18:49:12 -0700 >> Zac Medico wrote: > >>> The PROPERTIES approach still seems a lot simpler and practical to >>> me. It seems to me that the approach involving categories introduces >>> needless complexity without bringing any really useful benefits. >> Could you elaborate on this categories complexity? I think that the idea is to >> just use already available categories, not implementing additional PROPERTY >> for this functionality. > > > Forcing a relationship with the category name seems more complex and > less flexible than simply having the ability to define > PROPERTIES=virtual in any given ebuild. Let me explain a bit more in case it's not clear. By forcing a relationship between the category and some other property, and removing the flexibility that would exist had this relationship not been forced, you end up having to add the additional complexity of package splits in order to achieve what could have otherwise been accomplished without any package splits. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki01awACgkQ/ejvha5XGaMy6wCg3VMSZr4KyARF2RNyC5OSwxky yvEAn2lR8XOmBBqWC23sl4BZMST/VNcI =7oU2 -----END PGP SIGNATURE-----