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 1KZNJZ-0003bu-5M for garchives@archives.gentoo.org; Sat, 30 Aug 2008 10:04:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 4DAC5E039B; Sat, 30 Aug 2008 10:04:15 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 03079E039B for ; Sat, 30 Aug 2008 10:04:15 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 17C25672C7 for ; Sat, 30 Aug 2008 10:04:14 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.785 X-Spam-Level: X-Spam-Status: No, score=-0.785 required=5.5 tests=[AWL=0.747, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_NUMERIC_HELO=2.067] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSYWK3y87aWr for ; Sat, 30 Aug 2008 10:04:06 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 34DF4678A8 for ; Sat, 30 Aug 2008 10:04:05 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KZNJJ-0007ks-5g for gentoo-dev@gentoo.org; Sat, 30 Aug 2008 10:04:01 +0000 Received: from 82.152.217.73 ([82.152.217.73]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Aug 2008 10:04:01 +0000 Received: from slong by 82.152.217.73 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 30 Aug 2008 10:04:01 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition) Date: Sat, 30 Aug 2008 10:59:41 +0100 Message-ID: References: <48B1CC3C.2000103@gentoo.org> <20080825201217.194fecad@googlemail.com> <48B309C2.1060204@gentoo.org> <200808252103.27006.levertond@googlemail.com> <20080826142044.28367055@googlemail.com> 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 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.217.73 User-Agent: KNode/0.10.9 Sender: news X-Archives-Salt: 3cab58c9-6cff-4551-a617-1be0c5d2efec X-Archives-Hash: 7d7ed4a8266021d60a6405d6b3a2a411 Duncan wrote: > Ciaran McCreesh posted > 20080826142044.28367055@googlemail.com, excerpted below, on Tue, 26 Aug > 2008 14:20:44 +0100: > >> On Tue, 26 Aug 2008 06:39:38 +0000 (UTC) Duncan <1i5t5.duncan@cox.net> >> wrote: >>> But I think virtual works just fine for kde-base/kde, too, if one >>> simply reads it literally -- it's a virtual package in that it doesn't >>> install anything itself, even if it's a meta-package [...] >> >> So what does 'virtual' actually mean then, and how is it related to the >> defined behaviour of this property? > > I'm unsure of whether that was intended to be a rhetorical question or > not, so taking it literally... > Yeah, I think the original mail outlined the meaning quite explicitly, although this is good, perhaps for user documentation: > Opposite of real or physical. > > > So a virtual package would have the essence and effects of a real one > (dependencies and the like) but not be "real" in some way (here, zero- > install-cost, or more correctly, only the install cost of the > dependencies). > > More directly, a package that doesn't actually install anything itself, > only having dependencies that ensure other packages are installed. > > In original Gentoo usage, virtual packages didn't have ebuilds at all, > but referred to dependencies that several different packages could > provide, with the the profile generally specifying a default. Now many > of them have ebuilds, but the general idea of not installing anything > directly themselves, only thru dependencies, remains. This is equally > true of the original no-ebuild virtuals, those ebuilds in the virtual/ > categories, and various meta-packages such as kde and kde-meta. Thus, > they fit the broader defintion of "virtual" in a literal sense, > regardless of where they are located in the category tree. > I concur that it makes a lot of sense, fitting in exactly with the meaning originally given. That it means 'zero-install-cost' is neither here nor there imo; 'virtual' is a well understood terms for the same thing: an ebuild that doesn't in itself install anything. That kde and kde-meta are changing doesn't matter to the general suitability of the property for other meta ebuilds, although it'll be interesting to see if sets become the new method. Also, as outlined wrt live-cvs, specialisation of the base property is envisaged. > 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. > Yeuch ;) I agree with Zac on this aspect: > 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. It's clearly something that can be useful across the tree, and can apply to an ebuild as opposed to a package. Forcing a category (or a pkgmove which is a pita aiui) seems inelegant (and doesn't enable the second use-case); the property is far more appropriate, and as you say, 'virtual' is less confusing for a user than 'zero-install-cost', especially within Gentoo. PROPERTIES seems like it's going to be a very handy variable.