1 |
Duncan wrote: |
2 |
|
3 |
> Ciaran McCreesh <ciaran.mccreesh@××××××××××.com> posted |
4 |
> 20080826142044.28367055@××××××××××.com, excerpted below, on Tue, 26 Aug |
5 |
> 2008 14:20:44 +0100: |
6 |
> |
7 |
>> On Tue, 26 Aug 2008 06:39:38 +0000 (UTC) Duncan <1i5t5.duncan@×××.net> |
8 |
>> wrote: |
9 |
>>> But I think virtual works just fine for kde-base/kde, too, if one |
10 |
>>> simply reads it literally -- it's a virtual package in that it doesn't |
11 |
>>> install anything itself, even if it's a meta-package [...] |
12 |
>> |
13 |
>> So what does 'virtual' actually mean then, and how is it related to the |
14 |
>> defined behaviour of this property? |
15 |
> |
16 |
> I'm unsure of whether that was intended to be a rhetorical question or |
17 |
> not, so taking it literally... |
18 |
> |
19 |
Yeah, I think the original mail outlined the meaning quite explicitly, |
20 |
although this is good, perhaps for user documentation: |
21 |
|
22 |
> Opposite of real or physical. |
23 |
> |
24 |
> |
25 |
> So a virtual package would have the essence and effects of a real one |
26 |
> (dependencies and the like) but not be "real" in some way (here, zero- |
27 |
> install-cost, or more correctly, only the install cost of the |
28 |
> dependencies). |
29 |
> |
30 |
> More directly, a package that doesn't actually install anything itself, |
31 |
> only having dependencies that ensure other packages are installed. |
32 |
> |
33 |
> In original Gentoo usage, virtual packages didn't have ebuilds at all, |
34 |
> but referred to dependencies that several different packages could |
35 |
> provide, with the the profile generally specifying a default. Now many |
36 |
> of them have ebuilds, but the general idea of not installing anything |
37 |
> directly themselves, only thru dependencies, remains. This is equally |
38 |
> true of the original no-ebuild virtuals, those ebuilds in the virtual/ |
39 |
> categories, and various meta-packages such as kde and kde-meta. Thus, |
40 |
> they fit the broader defintion of "virtual" in a literal sense, |
41 |
> regardless of where they are located in the category tree. |
42 |
> |
43 |
I concur that it makes a lot of sense, fitting in exactly with the meaning |
44 |
originally given. That it means 'zero-install-cost' is neither here nor |
45 |
there imo; 'virtual' is a well understood terms for the same thing: an |
46 |
ebuild that doesn't in itself install anything. |
47 |
|
48 |
That kde and kde-meta are changing doesn't matter to the general suitability |
49 |
of the property for other meta ebuilds, although it'll be interesting to |
50 |
see if sets become the new method. Also, as outlined wrt live-cvs, |
51 |
specialisation of the base property is envisaged. |
52 |
|
53 |
> I therefore believe I like just moving them all to a *virtual*/ category |
54 |
> better, thus obviating the need for that particular property in the first |
55 |
> place. |
56 |
> |
57 |
Yeuch ;) I agree with Zac on this aspect: |
58 |
|
59 |
> existence of |
60 |
> meta-packages in the "java-virtuals" category [5], among others, |
61 |
> makes it useful to introduce the "virtual" property as a means to |
62 |
> identify these ebuilds. Note that some packages, such as x11-libs/qt |
63 |
> [6], exhibit this property for some versions and not others. So, in |
64 |
> some cases it may be useful to be able to specify the "virtual" |
65 |
> property separately for different ebuild versions. |
66 |
|
67 |
It's clearly something that can be useful across the tree, and can apply to |
68 |
an ebuild as opposed to a package. Forcing a category (or a pkgmove which |
69 |
is a pita aiui) seems inelegant (and doesn't enable the second use-case); |
70 |
the property is far more appropriate, and as you say, 'virtual' is less |
71 |
confusing for a user than 'zero-install-cost', especially within Gentoo. |
72 |
|
73 |
PROPERTIES seems like it's going to be a very handy variable. |