/[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.1 - (hide annotations) (download)
Thu Jun 15 14:36:52 2006 UTC (8 years, 4 months ago) by g2boojum
Branch: MAIN
File MIME type: text/plain
new glep

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

  ViewVC Help
Powered by ViewVC 1.1.20