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
|
<?xml version="1.0"?>
<guide self="general-concepts/slotting/">
<chapter>
<title>Slotting</title>
<body>
<p>
Packages can support having multiple versions installed simultaneously. This is
useful for libraries which may have changed interfaces between versions <d/> for
example, the <c>gtk+</c> package can install both versions <c>2.24</c> and <c>3.6</c> in
parallel. This feature is called slotting.
</p>
<p>
Most packages have no need for slotting. These packages specify <c>SLOT="0"</c>
in the ebuilds. This is purely a convention; the package manager does not treat
<c>0</c> any different from other slot values.
</p>
<note>
<c>SLOT</c> is a mandatory variable and must not be empty.
</note>
<p>
Portage permits at most one instance of a package installation <e>per <c>SLOT</c>
value</e>. For example, say we have the following:
</p>
<ul>
<li><c>foo-1.1</c> with <c>SLOT="1"</c></li>
<li><c>foo-1.2</c> with <c>SLOT="1"</c></li>
<li><c>foo-2.0</c> with <c>SLOT="2"</c></li>
<li><c>foo-2.1</c> with <c>SLOT="2"</c></li>
</ul>
<p>
Then the user could have, say, <c>foo-1.2</c> and <c>foo-2.0</c> installed in
parallel, but <e>not</e> <c>foo-1.1</c> and <c>foo-1.2</c>. Note that it is entirely
possible that the user may have <c>foo-2.0</c> installed and no <c>foo-1.x</c> at all.
</p>
<p>
To <c>DEPEND</c> upon a package in a specific slot, refer to
<uri link="::general-concepts/dependencies#SLOT Dependencies" />.
</p>
</body>
<section>
<title>Sub-Slots</title>
<body>
<p>
Sometimes a package installs a library that changes interfaces between versions,
but it's undesirable or inconvenient to allow some of these versions to be installed
simultaneously. In <c>EAPI=5</c> and higher, this situation can be handled by
using sub-slots, which are delimited from the regular slot by a <c>/</c> character,
as in <c>SLOT="slot/subslot"</c>. Packages can
<uri link="::general-concepts/dependencies#Slot Operators">request to be
automatically rebuilt</uri> when the subslot of a runtime dependency changes.
</p>
<p>
For example, suppose package <c>foo</c> installs a library whose soname is
different for different versions. It would be reasonable to use the soname version
as the sub-slot name:
</p>
<ul>
<li><c>foo-1.1</c> installs <c>libfoo.so.5</c> <d/> <c>SLOT="1/5"</c></li>
<li><c>foo-1.2</c> installs <c>libfoo.so.6</c> <d/> <c>SLOT="1/6"</c></li>
<li><c>foo-2.0</c> installs <c>libfoo-2.so.0</c> <d/> <c>SLOT="2/0"</c></li>
<li><c>foo-2.1</c> installs <c>libfoo-2.so.1</c> <d/> <c>SLOT="2/1"</c></li>
</ul>
<p>
Other ebuilds that install binaries which link to <c>libfoo-2</c> (or <c>libfoo</c>)
can then request to be automatically rebuilt when the installed version of
<c>foo:2</c> or <c>foo:1</c> changes sub-slots <d/> for example, when the user
upgrades from <c>foo-2.0</c> to <c>foo-2.1</c>.
</p>
<p>
If an ebuild does not explicitly declare a sub-slot, the regular slot is used
as the value of the sub-slot by default.
</p>
<note>
Care must be taken when using sub-slots in a library ebuild for the first time.
Adding sub-slots will trigger rebuilds for all the packages that already use sub-slot
dependencies (e.g. Switching from SLOT="0" to SLOT="0/14" in <c>media-libs/libpng</c> and
package <c>foo</c> depends on <c>libpng:0=</c>).
Therefore, it's best if you start using sub-slots in the library when the existing library
interface changes.
</note>
</body>
</section>
<section>
<title>Slot Names</title>
<body>
<p>
Current versions of portage accept slot and sub-slot names that begin with an
alphanumeric character or <c>'_'</c>, and contain alphanumerics and <c>'_'</c>,
<c>'-'</c>, <c>'.'</c>, and <c>'+'</c> characters.
</p>
</body>
</section>
</chapter>
</guide>
|
GitWeb