/[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.1 - (hide annotations) (download)
Sat Mar 6 23:19:05 2004 UTC (10 years, 4 months ago) by g2boojum
Branch: MAIN
File MIME type: text/plain
New GLEP

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

  ViewVC Help
Powered by ViewVC 1.1.20