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