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

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

Parent Directory Parent Directory | Revision Log Revision Log


Revision 1.3 - (show annotations) (download)
Tue Sep 5 20:54:30 2006 UTC (8 years, 2 months ago) by g2boojum
Branch: MAIN
CVS Tags: HEAD
Changes since 1.2: +12 -4 lines
File MIME type: text/plain
updates

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

  ViewVC Help
Powered by ViewVC 1.1.20