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