1 |
> -----BEGIN PGP SIGNED MESSAGE----- |
2 |
> Hash: SHA1 |
3 |
> |
4 |
> Hi all, |
5 |
> |
6 |
> I had another crazy idea that I'd like some feedback on. I'll jump |
7 |
> straight |
8 |
> in. With the current virtuals system, there are two basic deficiencies: |
9 |
> |
10 |
> 1. Packages that can provide a virtual based on USE flags can't. (#32114) |
11 |
> 2. Different versions of a virtual are not supported. (#46968) |
12 |
> |
13 |
> The proposal for 1 is to have PROVIDE use a syntax similar to DEPEND for |
14 |
> specifying any USE flag relationship. There is currently no proposal for |
15 |
> 2. |
16 |
> |
17 |
> What I'm proposing here is to drop virtuals altogether. Instead, I propose |
18 |
> using meta-packages similar to kde and gnome. To give a give a cut down |
19 |
> example: |
20 |
> |
21 |
> virtual/x11-1.ebuild: |
22 |
> RDEPEND="x86? ( || ( x11-base/xfree x11-base/xorg-x11 ) ) |
23 |
> sparc? ( || ( x11-base/xorg-x11 x11-base/xfree ) )" |
24 |
> |
25 |
> The -1 in x11-1 is an arbitrary version. This example shows the only |
26 |
> deficiency of doing it this way that I am able to think of. Instead of |
27 |
> specifying the default virtuals per profile, they would only be able to be |
28 |
> specified per architecture. |
29 |
> |
30 |
> Now to an example that shows a resolution to issue 2 above: |
31 |
> |
32 |
> virtual/jdk-1.4.ebuild: |
33 |
> RDEPEND="|| ( >=dev-java/blackdown-jdk-1.4 >=dev-java/kaffe-1.1.4 ... )" |
34 |
> |
35 |
> The different versions aspect is represented here by kaffe-1.1.4. Even it |
36 |
> is |
37 |
> installed it is presently not able to satisfy >=virtual/jdk-1.4 as its |
38 |
> version component does not match. |
39 |
|
40 |
:/ So, say I want my love-sources ebuild in my overlay to provide for |
41 |
virtual/winkernel (since some versions are patched with win4lin), Rather |
42 |
then editing the love-sources ebuild (which will survive an emerge sync), |
43 |
I have to edit this metaebuid for the virtual (which will not survive an |
44 |
emerge sync unless ) |
45 |
|
46 |
> As for issue number 1, it will require a (already scheduled) portage |
47 |
> enhancement: |
48 |
> |
49 |
> virtual/login-1.ebuild: |
50 |
> RDEPEND="|| sys-apps/shadow[pam] sys-apps/pam-login[-pam]" |
51 |
> |
52 |
> Here, shadow with USE="pam" or pam-login with USE="-pam" are supported. |
53 |
> |
54 |
> As a side note, a single atom is chosen || () dependencies. If something |
55 |
> installed satisfied any of the atoms, then the installed package is used. |
56 |
> Otherwise the first package in the list is used. |
57 |
> |
58 |
> Finally, there are two additional benefits. One is a slight speed increase |
59 |
> as |
60 |
> portage would no longer have to concern itself with virtuals. Second, is |
61 |
> that |
62 |
> it would be possible to find all packages that satisify a virtual without |
63 |
> scanning the entire tree for PROVIDEs. |
64 |
> |
65 |
> Do I burn in hell? (Again? ) |
66 |
|
67 |
>From portage-*.51 |
68 |
|
69 |
/var/cache/edb/virtuals has been deprecated and is now calculated" |
70 |
on demand. Strictly _USER_ modifications to virtuals may go into" |
71 |
/etc/portage/virtuals and will never be modified by portage. |
72 |
|
73 |
It would sound like there is already work to change virtuals around, and i |
74 |
assume that "calculated on demand" is pretty much the opposite of your |
75 |
idea. |
76 |
|
77 |
|
78 |
|
79 |
-- |
80 |
gentoo-dev@g.o mailing list |