1 |
On Sun, 27 Jun 2004 14:41:47 +0900 |
2 |
Jason Stubbs <jstubbs@g.o> wrote: |
3 |
|
4 |
> virtual/x11:RDEPEND="|| ( x11-base/xorg-x11 x11-base/xfree )" |
5 |
> portage/virtuals:virtual/x11 x11-base/xfree x11-base/xorg-x11 |
6 |
> expand to "|| ( x11-base/xfree x11-base/xorg-x11 |
7 |
> || ( x11-base/xorg-x11 x11-base/xfree ) )" |
8 |
|
9 |
That a good idea, but it works well only because the virtual dep |
10 |
formula is a global disjonction. But what if for instance someone |
11 |
writes an alsa virtual that looks like this: |
12 |
RDEPEND="|| ( media-sound/alsa-driver |
13 |
>=virtual/linux-sources-2.6 ) |
14 |
media-libs/alsa-lib" |
15 |
Then the user who wants his driver to be provided by kernel2.6 |
16 |
should probably write this in is virtuals file: |
17 |
virtual/alsa \ |
18 |
( >=virtual/linux-sources-2.6 media-libs/alsa-lib ) |
19 |
so that the RDEPEND is transformed into: |
20 |
"|| ( >=virtual/linux-sources-2.6 media-libs/alsa-lib ) |
21 |
( || ( media-sound/alsa-driver |
22 |
>=virtual/linux-sources-2.6 ) |
23 |
media-libs/alsa-lib )" |
24 |
|
25 |
Imho that's a bit too complicated, that's why i think |
26 |
expressiveness should be limited to a global disjonction. That |
27 |
said, it may be done by policy instead of being enforced by |
28 |
the code. |
29 |
|
30 |
On the same kind of idea, i was thinking about an helper tool for |
31 |
/etc/portage/virtuals (what ufed is to the USE var). If you are |
32 |
sure that virtuals dep is just a disjonction, then, for a given |
33 |
virtual, the tool can present to user the list of possible |
34 |
choices, and user only have to sort his prefered packages. But if |
35 |
you allow arbitrary formulae, then such a tool becomes harder |
36 |
to write and to understand for the user. |
37 |
|
38 |
> > That say, what is still hard is to know what virtuals a |
39 |
> > given package instanciates (which is required for instance for |
40 |
> > correct implementation of the buildsyspkg feature). |
41 |
|
42 |
Just to explain this point a bit more, have a look on bug #34964: |
43 |
The goal was to enable buildpkg for system ebuilds. An issue was |
44 |
that in profile, there are some system packages specified as |
45 |
virtuals. The implementation of this "buildsyspkg" feature that is |
46 |
currently in portage is broken in such cases (if profile ask for |
47 |
virtual/glibc, the sys-libs/glibc won't be recognized as a system |
48 |
package). Now that PROVIDES is an aux_get key, that would be easy |
49 |
to fix. But at the contrary, with your system, this link from a |
50 |
concrete package to the virtuals it instanciates disappears, so it |
51 |
can no more be fixed. That's a rather minor issue tho. |
52 |
|
53 |
A maybe more important one if PROVIDES disappears is that you |
54 |
loose some convenient shortcuts when using eclasses. For instance, |
55 |
for kernel sources, the eclass has PROVIDES=virtual/kernel (and a |
56 |
few other like this, some of which are conditional, etc.). With |
57 |
your system, every single kernel sources packages will have to be |
58 |
listed in the virtual ebuild. |
59 |
|
60 |
> Assuming no other packages come into play, hexxagon is now |
61 |
> broken as gtk+ would be unmerged. I think there's absolutely no |
62 |
> way to get around this other than to record what the package was |
63 |
> built against. What I was saying earlier is that this is a |
64 |
> current problem which must be fixed regardless of any change to |
65 |
> virtuals. |
66 |
|
67 |
Ok, now i understand better. and you're right that once the |
68 |
virtuals preferences of the user are integrated in the dep |
69 |
formula, as you've proposed, then it is no more special case |
70 |
for depclean. |
71 |
|
72 |
> > Imo, it should appear in db, but as a special case |
73 |
> |
74 |
> This is very easy. Just check for RESTRICT="metaebuild". |
75 |
|
76 |
Yes, i agree it seems rather straightforward to add this special |
77 |
case. |
78 |
|
79 |
|
80 |
-- |
81 |
TGL. |
82 |
|
83 |
-- |
84 |
gentoo-dev@g.o mailing list |