Duncan wrote: > Ciaran McCreesh <[EMAIL PROTECTED]> posted > [EMAIL PROTECTED], excerpted below, on Tue, 26 Aug > 2008 14:20:44 +0100: > >> On Tue, 26 Aug 2008 06:39:38 +0000 (UTC) Duncan <[EMAIL PROTECTED]> >> 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.
