--- xml/htdocs/proj/en/glep/glep-0021.html 2004/03/07 23:21:45 1.2 +++ xml/htdocs/proj/en/glep/glep-0021.html 2006/09/04 03:07:37 1.3 @@ -8,9 +8,252 @@ -->- +
|Title:||User-defined Package Sets|
|Author:||Tal Peer <coredumb at gentoo.org>+|
|Author:||Tal Peer <coredumb at gentoo.org>, +Alec Warner <antarus at gentoo.org>|
Taken over by antarus.+
In Portage, package sets (formerly known as 'classes' or 'targets') are mere groups of packages, grouped together to allow easier updating and handling of them. Currently it is impossible to define sets further than the two default ones: "system" and "world".
Over the months, quite a few requests for user-defined sets were made by users and developers, either by posting bugs, messages to mailing lists or on IRC. Usually the response is that this is an @@ -89,11 +337,11 @@ user-defined sets using configuration files similar to the current world/system sets use.
The proposed implementation uses a one file per set approach, meaning each package set is defined in a single file. All set definition files -will reside in a directory /etc/portage/sets/ and each set's name +will reside in a directory /etc/portage/sets/ and each set's name will be its file name. Therefore, if one defines a set in /etc/portage/sets/foo-set, the set name will be 'foo-set'. Usual package naming rules  also apply to sets.@@ -107,8 +355,8 @@ addition: sets may not be 'inherited' by other sets, only packages may be listed. There is no limitation to the number of packages in a set or to the number of sets a package may belong to. -
The user-defined sets will be available either directly or using the --package-set option, As in:
@@ -134,31 +382,31 @@ the current system-defined sets.
Only one set may be passed to portage at time, and sets can not be mixed with ordinary packages. Thus, the following snippets are -all invalid and will result in an error (assuming foo-set and -bar-set are defined as sets):+all invalid and will result in an error (assuming foo-set and +bar-set are defined as sets):emerge foo-set glibc emerge bar-set system emerge world foo-set gcc
The implementation of the package sets concept in Portage should be mostly done in portage.py, and only the interface parts should be added to emerge itself, to keep the separation between interface and @@ -166,16 +414,16 @@
The amount of work needed for implementation is not trivial, but not huge either.
The one file per set approach makes it easy to list the sets which are -defined on a system by just listing the /etc/portage/sets +defined on a system by just listing the /etc/portage/sets directory contents. Additionally, it makes the set lookup process more efficient as it only requires to check if a file exists.
I chose the --package-set option over the --set option for explicitly telling portage to emerge a set mostly because --set implies setting an environment variable, or such.-
Allowing sets' USE flags to be manipulated through the package.use +
Allowing sets' USE flags to be manipulated through the package.use file would have done more harm than good, for several reasons:
Therefore, I have decided it would be better to disallow setting USE flags for sets.
Backwards compatibility with the current situation, in which only two system-defined sets exist can be kept in one of two ways:
Other than that, there are no other backwards compatibility concerns involved.