1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
---
GLEP: 50
Title: Supporting alternative package managers
Author: Grant Goodyear <g2boojum@gentoo.org>
Type: Standards Track
Status: Rejected
Version: 1
Created: 2006-05-22
Last-Modified: 2014-01-23
Post-History: 2006-06-15, 2006-09-06
Content-Type: text/x-rst
---
Status
======
The council rejected this GLEP in favor of starting from a package manager
API and requiring Gentoo package managers in the tree to support that
API. (That API is still pending, however.)
Abstract
========
To support alternatives to the official package manager (portage, at the time
of this writing), some sane ground rules need to be set. Specifically, no
alternative ebuild-based package manager may be added to the tree unless it
successfully works with all ebuilds supported by the official package manager.
Moreover, no ebuilds may be added to the tree unless they are supported
(without change) by the official package manager.
Specification
=============
* No alternative ebuild-based package manager may be added
to the tree unless it successfully works with all ebuilds supported by
the official package manager. If an alternative package manager is
runtime incompatible with the official package manager, then it
must be masked and provide appropriate warnings.
* No ebuilds may be added to the tree unless they are supported
(without change) by the official package manager.
Rationale
=========
The first rule sets a reasonable bar for adding an alternative package
manager to the tree. Note that if an ebuild currently in the tree
doesn't work with the official package manager, it isn't expected to
work with an alternative package manager either. The second rule
ensures that an alternative package manager cannot become a de-facto
requirement by supporting packages that the official package manager
cannot handle.
In order to keep this proposal as simple and focused as possible, it has
nothing to say about the process by which an alternative package manager
might one day become the official package manager. It is assumed that
sanity will reign, and no package manager will become official without
being able to build installation media, providing a transition path from
or to the existing official package manager, etcetera.
Notes
=====
* An early criticism of this GLEP was that it fails to address eclasses and
profiles. As far as eclasses are concerned, my view is that the above rules
suffice, since eclasses only matter in their use in ebuilds. If a package
manager can effectively process all ebuilds, then it must be handling the
eclasses successfully, too. Profiles, on the other hand, are not addressed
here even implicitly.
* Assuming the ebuild specification is successfully finished, then the
first rule should really replace "all ebuilds supported by the official
package manager" with "all ebuilds that satisfy the ebuild spec".
Similarly, in rule two "by the official package manager" should
read "by the official ebuild spec".
Backwards Compatibility
=======================
Pretty much the whole point, and it's explicit here.
Copyright
=========
This work is licensed under the Creative Commons Attribution-ShareAlike 3.0
Unported License. To view a copy of this license, visit
https://creativecommons.org/licenses/by-sa/3.0/.
|
GitWeb