1 |
g2boojum |
1.1 |
GLEP: 21 |
2 |
|
|
Title: User-defined Package Sets |
3 |
g2boojum |
1.3 |
Version: $Revision: 1.2 $ |
4 |
|
|
Last-Modified: $Date: 2004/03/07 23:20:54 $ |
5 |
|
|
Author: Tal Peer <coredumb@gentoo.org>, |
6 |
|
|
Alec Warner <antarus@gentoo.org> |
7 |
g2boojum |
1.1 |
Status: Draft |
8 |
|
|
Type: Standards Track |
9 |
|
|
Discussed-To: gentoo-portage-dev@lists.gentoo.org |
10 |
|
|
Content-Type: text/x-rst |
11 |
|
|
Created: 22-Feb-2004 |
12 |
g2boojum |
1.3 |
Post-History: 6-Mar-2004, 3-Sep-2006 |
13 |
|
|
|
14 |
|
|
Status |
15 |
|
|
====== |
16 |
|
|
|
17 |
|
|
Taken over by antarus. |
18 |
g2boojum |
1.1 |
|
19 |
|
|
|
20 |
|
|
Abstract |
21 |
|
|
======== |
22 |
|
|
|
23 |
|
|
In Portage, package sets (formerly known as 'classes' or 'targets') |
24 |
|
|
are mere groups of packages, grouped together to allow easier updating |
25 |
|
|
and handling of them. Currently it is impossible to define sets further |
26 |
|
|
than the two default ones: "system" and "world". |
27 |
|
|
|
28 |
|
|
Motivation |
29 |
|
|
========== |
30 |
|
|
|
31 |
|
|
Over the months, quite a few requests for user-defined sets were |
32 |
|
|
made by users and developers, either by posting bugs, messages to |
33 |
|
|
mailing lists or on IRC. Usually the response is that this is an |
34 |
|
|
awesome idea, but no one ever took the time to actually define it |
35 |
|
|
properly and implement it. |
36 |
|
|
|
37 |
|
|
This document offers a specification for the implementation of |
38 |
|
|
user-defined sets using configuration files similar to the current |
39 |
|
|
world/system sets use. |
40 |
|
|
|
41 |
|
|
Specification |
42 |
|
|
============= |
43 |
|
|
|
44 |
|
|
The proposed implementation uses a one file per set approach, meaning |
45 |
|
|
each package set is defined in a single file. All set definition files |
46 |
|
|
will reside in a directory ``/etc/portage/sets/`` and each set's name |
47 |
|
|
will be its file name. Therefore, if one defines a set in |
48 |
|
|
/etc/portage/sets/foo-set, the set name will be 'foo-set'. Usual |
49 |
|
|
package naming rules [#NAME-RULES]_ also apply to sets. |
50 |
|
|
|
51 |
|
|
As it is impossible to create two or more files with identical names |
52 |
|
|
in the same directory, a theoretic conflict between two different sets |
53 |
|
|
sharing the same name is impossible. However, users may define a |
54 |
|
|
package set whose name conflicts with one more or packages (for ambiguity |
55 |
|
|
resolution, see below). |
56 |
|
|
|
57 |
|
|
Syntax for the package list file is the same as the world file syntax, |
58 |
|
|
as described in the Portage manpage [#PORTAGE-MANPAGE]_, with one |
59 |
|
|
addition: sets may not be 'inherited' by other sets, only packages may |
60 |
|
|
be listed. There is no limitation to the number of packages in a set |
61 |
|
|
or to the number of sets a package may belong to. |
62 |
|
|
|
63 |
|
|
Using User-defined Sets With Emerge |
64 |
|
|
-------------------------------------- |
65 |
|
|
|
66 |
|
|
The user-defined sets will be available either directly or using |
67 |
|
|
the --package-set option, As in:: |
68 |
|
|
|
69 |
|
|
# Basically the same: |
70 |
|
|
emerge foo-set |
71 |
|
|
emerge --package-set foo-set |
72 |
|
|
|
73 |
|
|
The --package-set option is introduced to bypass ambiguities, as |
74 |
|
|
illustrated in the next example:: |
75 |
|
|
|
76 |
|
|
emerge foo # Where foo is both a set and a one or more |
77 |
|
|
# existing packages. This will cause emerge to show |
78 |
|
|
# the ambiguity, ask us to be more |
79 |
|
|
# specific, and stop. |
80 |
|
|
|
81 |
|
|
emerge --package-set foo # So we specify that what we actually |
82 |
|
|
# meant was the package set. |
83 |
|
|
|
84 |
|
|
emerge cat-bar/foo # Or we specify the exact package name. |
85 |
|
|
|
86 |
|
|
When running emerge with the --pretend option, sets will be |
87 |
|
|
expanded to the packages they are comprised off in the output, as with |
88 |
|
|
the current system-defined sets. |
89 |
|
|
|
90 |
|
|
Only one set may be passed to portage at time, and sets can not |
91 |
|
|
be mixed with ordinary packages. Thus, the following snippets are |
92 |
|
|
all invalid and will result in an error (assuming ``foo-set`` and |
93 |
|
|
``bar-set`` are defined as sets):: |
94 |
|
|
|
95 |
|
|
emerge foo-set glibc |
96 |
|
|
emerge bar-set system |
97 |
|
|
emerge world foo-set gcc |
98 |
|
|
|
99 |
|
|
Compatibility With Other Portage Features |
100 |
|
|
----------------------------------------- |
101 |
|
|
|
102 |
|
|
* Dependencies: |
103 |
|
|
Package sets (both system-defined and user-defined) may not be |
104 |
|
|
depended on by ordinary packages and eclasses. |
105 |
|
|
|
106 |
|
|
* package.mask: |
107 |
|
|
Masking a package set through the ``package.mask`` file is forbidden. |
108 |
g2boojum |
1.2 |
In order to 'mask' a package set, one should move it away from the |
109 |
|
|
sets directory. |
110 |
g2boojum |
1.1 |
|
111 |
|
|
* package.use: |
112 |
|
|
USE flags may not be defined for sets in the ``package.use`` file. |
113 |
|
|
|
114 |
|
|
Implementation |
115 |
|
|
============== |
116 |
|
|
|
117 |
|
|
The implementation of the package sets concept in Portage should be |
118 |
|
|
mostly done in portage.py, and only the interface parts should be |
119 |
|
|
added to emerge itself, to keep the separation between interface and |
120 |
|
|
logic. |
121 |
|
|
|
122 |
|
|
The amount of work needed for implementation is not trivial, but not |
123 |
|
|
huge either. |
124 |
|
|
|
125 |
|
|
Rationale |
126 |
|
|
========= |
127 |
|
|
|
128 |
|
|
The one file per set approach makes it easy to list the sets which are |
129 |
|
|
defined on a system by just listing the ``/etc/portage/sets`` |
130 |
|
|
directory contents. Additionally, it makes the set lookup process more |
131 |
|
|
efficient as it only requires to check if a file exists. |
132 |
|
|
|
133 |
|
|
I chose the --package-set option over the --set option for explicitly |
134 |
|
|
telling portage to emerge a set mostly because --set implies setting |
135 |
|
|
an environment variable, or such. |
136 |
|
|
|
137 |
|
|
Allowing sets' USE flags to be manipulated through the ``package.use`` |
138 |
|
|
file would have done more harm than good, for several reasons: |
139 |
|
|
|
140 |
|
|
- If a USE flag is turned on (i.e. 'foo') for a set and the same USE |
141 |
|
|
flag is turned off (i.e. '-foo'), for a package which is part of |
142 |
|
|
the set, it is unclear which setting should take precedence. |
143 |
|
|
|
144 |
|
|
- Similarly, if a USE flag is turned on for a set and the same USE flag |
145 |
|
|
is turned off for a set that is a subset of the original set, it is |
146 |
|
|
unclear which setting should take precedence. |
147 |
|
|
|
148 |
|
|
- If a USE flag is defined (either off or on) for a set and a package |
149 |
|
|
that belongs in the set is to be emerged, it is unclear whether the |
150 |
|
|
USE flag should be defined when emerging the package in question. |
151 |
|
|
|
152 |
|
|
Therefore, I have decided it would be better to disallow setting USE |
153 |
|
|
flags for sets. |
154 |
|
|
|
155 |
|
|
Backwards Compatibility |
156 |
|
|
======================= |
157 |
|
|
|
158 |
|
|
Backwards compatibility with the current situation, in which only two |
159 |
|
|
system-defined sets exist can be kept in one of two ways: |
160 |
|
|
|
161 |
|
|
1. Leaving the situation as is - the 'world' and 'system' sets are |
162 |
|
|
hard-coded in Portage. |
163 |
|
|
2. Distributing default 'system' and 'world' files under the |
164 |
|
|
``/etc/portage/sets/`` directory. |
165 |
|
|
|
166 |
|
|
Other than that, there are no other backwards compatibility concerns |
167 |
|
|
involved. |
168 |
|
|
|
169 |
|
|
References |
170 |
|
|
========== |
171 |
|
|
|
172 |
|
|
.. [#NAME-RULES] Gentoo Linux Development Policy - Ebuild Policy |
173 |
|
|
(http://www.gentoo.org/doc/en/policy.xml#doc_chap3) |
174 |
|
|
|
175 |
|
|
.. [#PORTAGE-MANPAGE] |
176 |
|
|
http://www.gentoo.org/cgi-bin/viewcvs.cgi/portage/man/portage.5?root=gentoo-src |
177 |
|
|
|
178 |
|
|
Copyright |
179 |
|
|
========= |
180 |
|
|
|
181 |
|
|
This document has been placed in the public domain. |
182 |
|
|
|