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 1KYA9l-0000jw-Cy for garchives@archives.gentoo.org; Wed, 27 Aug 2008 01:49:09 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7E82FE013D; Wed, 27 Aug 2008 01:49:08 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 56440E013D for ; Wed, 27 Aug 2008 01:49:08 +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 5DEBA65F05 for ; Wed, 27 Aug 2008 01:49:07 +0000 (UTC) Message-ID: <48B4B298.5030005@gentoo.org> Date: Tue, 26 Aug 2008 18:49:12 -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> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: fa039dae-4c9a-4b23-9f99-7abd5fbc3eb5 X-Archives-Hash: a14277dee96a8153923bb08f8dae3627 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Duncan wrote: > Zac Medico posted 48B440F6.7020705@gentoo.org, > excerpted below, on Tue, 26 Aug 2008 10:44:22 -0700: > >> Duncan wrote: >>> I therefore believe I like just moving them all to a *virtual*/ >>> category better, thus obviating the need for that particular property >>> in the first place. >> This has been suggested elsewhere in the thread [1] but I think the the >> PROPERTIES approach will be more flexible and practical for the reasons >> that I've already stated. >> >> [1] >> http://archives.gentoo.org/gentoo-dev/ > msg_65636255c9d284e51898e826cae09ffd.xml > > Maybe it's just 'cause I'm not a dev, but I don't see the reasons you > state there as a problem. I specifically addressed the java-virtuals > category by suggesting that the trigger could be on "virtual" in the > category, not on the single category "virtual", so java-virtuals would be > included as would any other *virtual* category, and the java folks > wouldn't have to move it after all. > > Moves as for kde/kde-meta might be an issue, but I don't believe any more > so than any other package move, and since they're "virtual", possibly > less so. The splits, as for qt, might be more confusing, but it's a > one-time split either now or (for future packages) whenever they go > virtual, at which point there's a lot of work going into them anyway. > >>>From my perspective, that's not significant additional cost, at least > compared to the cost associated with the PROPERTIES=virtual in the first > place. Given the advantages, including the clarity of having the virtual > property out where all can see it in the category name itself, I think > it's worth the relatively small additional cost. > > That said, it'd be nice, and to me, worth the cost, particularly as > compared to the cost of implementing a new property anyway, but since I'm > not the one implementing it (in either the PM or the packages), feel free > to override that opinion. > > There's also conceivably some times when a virtual/pkg_name might not be > a proper fit regardless of the property, making the category proposal > somewhat less flexible. I can't think of anywhere that such might be the > case, but that doesn't mean there aren't such cases. But I still believe > the benefit of having the property out there for all to see more valuable > than any potentially lost flexibility. > 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. - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAki0spcACgkQ/ejvha5XGaOTygCg0phbwIFENXHBKyKryAMkgQwo RJwAoOdcjRUJAmnPK/RTBV5S0REVaYhx =QzgD -----END PGP SIGNATURE-----