[gentoo-dev] Re: Re: [RFC] PROPERTIES=virtual for meta-packages (clarification of definition)

[Steve Long <slong@rathaus.eclipse.co.uk>]

Ciaran McCreesh wrote:

> On Sat, 30 Aug 2008 10:59:41 +0100
> Steve Long <slong@rathaus.eclipse.co.uk> 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.)