1 |
On Mon, 25 Aug 2008 11:01:01 -0700 |
2 |
Zac Medico <zmedico@g.o> wrote: |
3 |
|
4 |
> Michal Kurgan wrote: |
5 |
> > On Sun, 24 Aug 2008 14:01:48 -0700 |
6 |
> > Zac Medico <zmedico@g.o> wrote: |
7 |
> > |
8 |
> >> Hi everyone, |
9 |
> >> |
10 |
> >> Since there were some questions about ambiguity in the meaning of |
11 |
> >> the proposed PROPERTIES=virtual [1] value, we need to clarify it. |
12 |
> >> |
13 |
> >> [ ... ] |
14 |
> >> |
15 |
> >> Ebuilds that exhibit the "virtual" property commonly serve as a |
16 |
> >> layer of indirection in dependencies. All of the ebuilds in the |
17 |
> >> existing "virtual" category [4] should be eligible to define |
18 |
> >> PROPERTIES=virtual. If the ebuilds in the virtual category were the |
19 |
> >> only ones that exhibited this "virtual" property, then the |
20 |
> >> information that PROPERTIES=virtual represents could simply be |
21 |
> >> inferred from membership of that category. However, existence of |
22 |
> >> meta-packages in the "java-virtuals" category [5], among others, |
23 |
> >> makes it useful to introduce the "virtual" property as a means to |
24 |
> >> identify these ebuilds. Note that some packages, such as x11-libs/qt |
25 |
> >> [6], exhibit this property for some versions and not others. So, in |
26 |
> >> some cases it may be useful to be able to specify the "virtual" |
27 |
> >> property separately for different ebuild versions. |
28 |
> >> |
29 |
> > |
30 |
> > Wouldn't it be more appropriate to just move the "offending" ebuilds to |
31 |
> > virtual category? e.g. virtual/qt, etc. |
32 |
> > |
33 |
> |
34 |
> A package move doesn't seem very practical given that the "virtual" |
35 |
> property varies from one version to the next. I suppose it could be |
36 |
> done as a split where older versions continue to exist as |
37 |
> x11-libs/qt and newer versions exist as virtual/qt. |
38 |
|
39 |
Exactly. I think that this distinction is more clear, both for users and |
40 |
developers. You've got the idea about package just from its name, not |
41 |
internal structure such as PROPERTIES or DESCRIPTION variables. |
42 |
|
43 |
> If we take that approach then you'll have to convince the java team to |
44 |
> combine the whole java-virtuals category [1] into the virtual category. The |
45 |
> same goes for any other meta-packages such as kde-meta-* or whatnot. |
46 |
> |
47 |
> [1] http://packages.gentoo.org/category/java-virtuals |
48 |
|
49 |
Hmm... looks like though work, but will try at least. Thanks for hint. |
50 |
|
51 |
If java hears that, what do you think about that? Are there any problems |
52 |
with doing such migration? |
53 |
|
54 |
> >> - -- |
55 |
> >> Thanks, |
56 |
> >> Zac |
57 |
> - -- |
58 |
> Thanks, |
59 |
> Zac |
60 |
|
61 |
-- |
62 |
Michal Kurgan |
63 |
http://dev.gentoo.org/~moloh |