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

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

Parent Directory Parent Directory | Revision Log Revision Log | View Patch Patch

Revision 1.1 Revision 1.3
1GLEP: 50 1GLEP: 50
2Title: Supporting alternative package managers 2Title: Supporting alternative package managers
3Version: $Revision: 1.1 $ 3Version: $Revision: 1.3 $
4Last-Modified: $Date: 2006/06/15 14:36:52 $ 4Last-Modified: $Date: 2006/09/05 20:54:30 $
5Author: Grant Goodyear <g2boojum@gentoo.org> 5Author: Grant Goodyear <g2boojum@gentoo.org>
6Status: Draft 6Status: Rejected
7Type: Standards Track 7Type: Standards Track
8Content-Type: text/x-rst 8Content-Type: text/x-rst
9Created: 22-May-2006 9Created: 22-May-2006
10Post-History: 15-Jun-2006 10Post-History: 15-Jun-2006, 6-Sep-2006
11
12Status
13======
14
15The council rejected this GLEP in favor of starting from a package manager
16API and requiring Gentoo package managers in the tree to support that
17API. (That API is still pending, however.)
18
11 19
12Abstract 20Abstract
13======== 21========
14 22
15To support alternatives to the official package manager (portage, at the time 23To support alternatives to the official package manager (portage, at the time
47might one day become the official package manager. It is assumed that 55might one day become the official package manager. It is assumed that
48sanity will reign, and no package manager will become official without 56sanity will reign, and no package manager will become official without
49being able to build installation media, providing a transition path from 57being able to build installation media, providing a transition path from
50or to the existing official package manager, etcetera. 58or to the existing official package manager, etcetera.
51 59
52Note 60Notes
53==== 61=====
54 62
55An early criticism of this GLEP was that it fails to address eclasses and 63* An early criticism of this GLEP was that it fails to address eclasses and
56profiles. As far as eclasses are concerned, my view is that the above rules 64 profiles. As far as eclasses are concerned, my view is that the above rules
57suffice, since eclasses only matter in their use in ebuilds. If a package 65 suffice, since eclasses only matter in their use in ebuilds. If a package
58manager can effectively process all ebuilds, then it must be handling the 66 manager can effectively process all ebuilds, then it must be handling the
59eclasses successfully, too. Profiles, on the other hand, are not addressed 67 eclasses successfully, too. Profiles, on the other hand, are not addressed
60here even implicitly. 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".
61 74
62Backwards Compatibility 75Backwards Compatibility
63======================= 76=======================
64 77
65Pretty much the whole point, and it's explicit here. 78Pretty much the whole point, and it's explicit here.

Legend:
Removed from v.1.1  
changed lines
  Added in v.1.3

  ViewVC Help
Powered by ViewVC 1.1.20