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 1KXgNG-0008KF-7n for garchives@archives.gentoo.org; Mon, 25 Aug 2008 18:01:06 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E0244E0391; Mon, 25 Aug 2008 18:01:01 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B95EDE0391 for ; Mon, 25 Aug 2008 18:01:01 +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 C564E64188 for ; Mon, 25 Aug 2008 18:01:00 +0000 (UTC) Message-ID: <48B2F35D.4080801@gentoo.org> Date: Mon, 25 Aug 2008 11:01:01 -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] [RFC] PROPERTIES=virtual for meta-packages (clarification of definition) References: <48B1CC3C.2000103@gentoo.org> <20080825115133.0d1e3db4@kurgan01.ece.ualberta.ca> In-Reply-To: <20080825115133.0d1e3db4@kurgan01.ece.ualberta.ca> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 70facd22-d346-4e24-8053-dd2e520d70f7 X-Archives-Hash: 65636255c9d284e51898e826cae09ffd -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Michal Kurgan wrote: > On Sun, 24 Aug 2008 14:01:48 -0700 > Zac Medico wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> Hi everyone, >> >> Since there were some questions about ambiguity in the meaning of >> the proposed PROPERTIES=virtual [1] value, we need to clarify it. >> >> [ ... ] >> >> Ebuilds that exhibit the "virtual" property commonly serve as a >> layer of indirection in dependencies. All of the ebuilds in the >> existing "virtual" category [4] should be eligible to define >> PROPERTIES=virtual. If the ebuilds in the virtual category were the >> only ones that exhibited this "virtual" property, then the >> information that PROPERTIES=virtual represents could simply be >> inferred from membership of that category. However, existence of >> meta-packages in the "java-virtuals" category [5], among others, >> makes it useful to introduce the "virtual" property as a means to >> identify these ebuilds. Note that some packages, such as x11-libs/qt >> [6], exhibit this property for some versions and not others. So, in >> some cases it may be useful to be able to specify the "virtual" >> property separately for different ebuild versions. >> > > Wouldn't it be more appropriate to just move the "offending" ebuilds to > virtual category? e.g. virtual/qt, etc. > A package move doesn't seem very practical given that the "virtual" property varies from one version to the next. I suppose it could be done as a split where older versions continue to exist as x11-libs/qt and newer versions exist as virtual/qt. If we take that approach then you'll have to convince the java team to combine the whole java-virtuals category [1] into the virtual category. The same goes for any other meta-packages such as kde-meta-* or whatnot. [1] http://packages.gentoo.org/category/java-virtuals >> - -- >> Thanks, >> Zac > - -- Thanks, Zac -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiy81wACgkQ/ejvha5XGaNqfACg0jO+/Tk6s7+wVxHJoBtO+guU D3EAoKKs5LQbq+KDui8mJ/fVKyYf9N+v =8Aaf -----END PGP SIGNATURE-----