1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
<?xml version="1.0" encoding="UTF-8"?>
<devbook self="general-concepts/virtuals/">
<chapter>
<title>Virtuals</title>
<body>
<p>
Virtuals are merely packages that are in the category of <c>virtual</c>. They
use their dependency string to specify the providers for the virtual and do
not install any files. Since they are regular ebuilds, there can be several
versions of a virtual (which can be helpful when a package may be provided by
another in some versions, and not others <d/> see the perl virtuals for an
example of this). One other difference (besides not installing any files) is
that a virtual does not define <c>HOMEPAGE</c> and <c>LICENSE</c> variables.
Since it installs no files, it really does not have a license.
</p>
<p>
Before adding a new virtual, it should be discussed on <c>gentoo-dev</c>.
</p>
<p>
An example of a virtual:
</p>
<codesample lang="ebuild">
EAPI=8
DESCRIPTION="Virtual for C++ tr1 <type_traits>"
SLOT="0"
KEYWORDS="~alpha amd64 arm hppa ~ia64 ~mips ppc ppc64 ~s390 sparc x86 ~x64-macos"
RDEPEND="|| ( >=sys-devel/gcc-4.1 dev-libs/boost )"
</codesample>
<p>
Looks familar...right? It should since it's going to look just like a regular
ebuild.
</p>
<note>
The so-called <e>old-style</e> or <c>PROVIDE</c> type virtuals have been banned
from the Gentoo repository.
</note>
</body>
<section>
<title>KEYWORDS in virtual packages</title>
<body>
<p>
Since virtual packages do not install any files, they do not follow the regular
arch testing procedure. Instead, the developer can immediately set
the <c>KEYWORDS</c> of a virtual to the union of <c>KEYWORDS</c> of its
providers. In particular, if a new virtual is created for a stable package,
the virtual is committed straight to stable.
</p>
<p>
For example, if you have two packages: <c>dev-libs/liblinux</c> with
<c>KEYWORDS="amd64 ~x86"</c> and <c>dev-libs/libbsd</c> with
<c>KEYWORDS="~amd64-fbsd ~x86-fbsd"</c>, the resulting virtual will
have:
</p>
<codesample lang="ebuild">
KEYWORDS="amd64 ~x86 ~amd64-fbsd ~x86-fbsd"
RDEPEND="|| ( dev-libs/liblinux dev-libs/libbsd )"
</codesample>
</body>
</section>
<section>
<title>Virtuals and subslots</title>
<body>
<warning>
This section is only applicable if virtual providers include versions that
are ABI-compatible with one another (and use matching SONAMEs) and/or
the incompatible providers are being obsoleted.
</warning>
<p>
Like regular packages, virtuals can define subslots that can be used
to trigger rebuilds of their reverse dependencies. For this to work, a new
version of the virtual is created for each subslot of the providers,
where each version contains dependencies on a specific subslot.
</p>
<p>
For example, a virtual for different packages providing ABI-compatible
<c>libfoo.so.1</c> libraries could look like the following:
</p>
<codesample lang="ebuild">
EAPI=8
DESCRIPTION="Virtual for libfoo.so.1"
SLOT="0/1"
RDEPEND="
|| (
dev-libs/libfoo:0/1
dev-libs/libfoo-alternate:0/1
dev-libs/bigpack:0/libfoo-1+libbar-0
dev-libs/bigpack:0/libfoo-1+libbar-1
)
"
</codesample>
<p>
Virtuals can also be used when one of the providers is being obsoleted in favor
of another that breaks ABI compatibility while remaining API-compatible. In this
case, multiple versions of the virtual are created, each specifying a single
provider and a unique subslot.
</p>
<p>
For example, if <c>dev-libs/libfoo</c> (<c>libfoo.so.0</c>) is being replaced
by <c>dev-libs/newfoo</c> (<c>libfoo.so.1</c>), <c>virtual/libfoo-0.ebuild</c>
would contain:
</p>
<codesample lang="ebuild">
EAPI=8
DESCRIPTION="Virtual for libfoo.so.0"
SLOT="0/0"
RDEPEND="dev-libs/libfoo:0/0"
</codesample>
<p>
while <c>virtual/libfoo-1.ebuild</c> would contain:
</p>
<codesample lang="ebuild">
EAPI=8
DESCRIPTION="Virtual for libfoo.so.1"
SLOT="0/1"
RDEPEND="dev-libs/newfoo:0/1"
</codesample>
<note>
In this case, the package manager will naturally want to upgrade
to <c>dev-libs/newfoo</c> whenever possible. Therefore, this solution
is not viable if a clean choice between the two providers is desired.
</note>
</body>
</section>
</chapter>
</devbook>
|
GitWeb