[gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
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 + (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.
Re: [gentoo-dev] Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
On Sat, 30 Aug 2008 10:59:41 +0100 Steve Long [EMAIL PROTECTED] wrote: 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. Except that that's not what it's being used to mean. It's being used to mean the cost of selecting this when doing dependency resolution cost analysis is zero, which is an entirely different thing. 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. Users don't need to see it. Heck, most developers don't need to see it. -- Ciaran McCreesh signature.asc Description: PGP signature
[gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)
Ciaran McCreesh wrote: On Sat, 30 Aug 2008 10:59:41 +0100 Steve Long [EMAIL PROTECTED] wrote: 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. Except that that's not what it's being used to mean. It's being used to mean the cost of selecting this when doing dependency resolution cost analysis is zero, which is an entirely different thing. So it's zero-resolution-cost now? Yes, that *is* different (although I'd use free-resolve. free is well understood as often meaning zero-cost, which isn't a phrase most English-speaking people use. It only has meaning within the PROPERTIES variable, so it's not going to clash with anything.) 'Since new-style virtuals are a type of meta-package, I'd prefer that we introduce some type of package metadata into the EAPI that distiguishes meta-packages (those that do not install anything) from normal packages.'[1] 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. Users don't need to see it. Heck, most developers don't need to see it. Well any dev using it will do, and I believe most of them start out as users. Anyone reading the ebuild will see it, and the fact that it's a well-understood term, within Gentoo at least[2], makes it easier for the PM user-base to work with. It's a cultural people understand this already point as opposed to a technical make-it-as-explicit-as-we-can one. That it's easier to scan and type is a bonus. [1] http://bugs.gentoo.org/show_bug.cgi?id=141118#c5 (bug has previously been cited as part of the motivation for this property.) [2] Of course for a new project, one could use whichever term one felt like, since users would be expecting a divergent codebase. Heck, it might even be worth changing names of stuff just for the sake of appearing shiny (or to kill backward-compatibility, or make it harder for people to make the mental switch back. Every little helps.)
[gentoo-dev] Last rites: media-sound/gogo
Masked media-sound/gogo for removal. Upstream seems dead and it doesn't build with nasm-2 Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED]
