Title:Supporting alternative package managers
Last-Modified:2006/06/15 14:36:52
Author:Grant Goodyear <g2boojum at>
Type:Standards Track



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.



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.


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.

Backwards Compatibility

Pretty much the whole point, and it's explicit here.


This document has been placed in the public domain.