/[gentoo]/xml/htdocs/proj/en/glep/glep-0021.txt
Gentoo

Contents of /xml/htdocs/proj/en/glep/glep-0021.txt

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.4 - (hide annotations) (download)
Sat Apr 21 03:13:16 2007 UTC (7 years, 5 months ago) by antarus
Branch: MAIN
Changes since 1.3: +3 -3 lines
File MIME type: text/plain
Two gleps are Rejected, a bunch moving from Draft -> Deferred since no one is working on them

1 g2boojum 1.1 GLEP: 21
2     Title: User-defined Package Sets
3 antarus 1.4 Version: $Revision: 1.3 $
4     Last-Modified: $Date: 2006/09/04 03:06:32 $
5 g2boojum 1.3 Author: Tal Peer <coredumb@gentoo.org>,
6     Alec Warner <antarus@gentoo.org>
7 antarus 1.4 Status: Deferred
8 g2boojum 1.1 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.

  ViewVC Help
Powered by ViewVC 1.1.20