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.)
