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

[Duncan]

Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> posted
20080826142044.28367055@××××××××××.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@×××.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...

According to kdict/WordNet:

        2: being such in essence or effect though not in actual fact

Extending that to the technical/computing realm, again kdict, this time 
FOLDOC and Jargon file:

        <jargon, architecture> (Via the technical term virtual
        memory, probably from the term "virtual image" in optics)

        1. Common alternative to logical; often used to refer to the
        artificial objects (like addressable virtual memory larger
        than physical memory) created by a computer system to help the
        system control access to shared resources.
     
        2. Simulated; performing the functions of something that isn't
        really there.  An imaginative child's doll may be a virtual
        playmate.
     
        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.

However, I like the idea someone else proposed as well.  Move all these 
packages into the virtual category.  That could of course be expanded to 
include java-virtuals if desired, since virtual is still part of the 
category name.  Either as a single category or as anything with "virtual" 
in the category, this would make things easier for both the package 
manager (making the property unnecessary) and the user, who would then 
know on sight (in the tab-completion and in --pretend/ask as well as 
various $PM messages) which packages were virtual.  

Putting all virtual packages in the virtual category/ies would certainly 
simplify the task of explaining to confused users why removing say kde-
base/games wanted to remove virtual/kde (instead of kde-base/kde), but 
wouldn't directly remove kdebase (tho emerge --depclean would then want 
to do so, until the user did an emerge --no-replace kdebase, at least), 
to use an example I saw in a different context recently.

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman