| 1 |
GLEP: 49 |
| 2 |
Title: Alternative Package Manager requirements |
| 3 |
Version: $Revision: 2218 $ |
| 4 |
Last-Modified: $Date: 2006-05-20 20:39:14 +0200 (Sat, 20 May 2006) $ |
| 5 |
Author: Paul de Vrieze <pauldv@gentoo.org>, |
| 6 |
Status: Draft |
| 7 |
Type: Standards Track |
| 8 |
Content-Type: text/x-rst |
| 9 |
Created: 18-May-2006 |
| 10 |
Post-History: 19-May-2006 |
| 11 |
|
| 12 |
|
| 13 |
Abstract |
| 14 |
======== |
| 15 |
|
| 16 |
This GLEP describes four classes of package managers. What the requirements for |
| 17 |
them are, and what support they can receive. |
| 18 |
|
| 19 |
|
| 20 |
Motivation |
| 21 |
========== |
| 22 |
|
| 23 |
To set a standard that package managers that seek Gentoo project approval and |
| 24 |
support should adhere to. |
| 25 |
|
| 26 |
|
| 27 |
Rationale |
| 28 |
========= |
| 29 |
|
| 30 |
Currently Portage is showing its age. The code of Portage does not seem to be |
| 31 |
salvageable for new versions. As of the date of publication, there are two known |
| 32 |
alternative package managers that claim a level of Portage compatibility. These |
| 33 |
alternatives are `paludis`_ and `pkgcore`_. Before these alternatives are |
| 34 |
developed further, a set of rules should be created to level the playing field |
| 35 |
and ensuring that decisions can be made clearly. |
| 36 |
|
| 37 |
|
| 38 |
Backwards Compatibility |
| 39 |
======================= |
| 40 |
|
| 41 |
Not a problem for this GLEP. There is no previous standard as the issue did not |
| 42 |
exist before. This GLEP is to prevent future compatibility issues. |
| 43 |
|
| 44 |
|
| 45 |
Categories of package managers |
| 46 |
============================== |
| 47 |
|
| 48 |
We distinguish four categories of package managers. While a package manager can |
| 49 |
transition from one category to another, it can not be in two categories at the |
| 50 |
same time. It can be in a state of transition though. |
| 51 |
|
| 52 |
*Primary Package Manager* |
| 53 |
There is one primary package manager. Currently this position is held by |
| 54 |
Portage. The primary package manager is assigned by the council and all |
| 55 |
packages in the official tree must be installable by a usable version of the |
| 56 |
primary package manager. |
| 57 |
|
| 58 |
*Candidate Primary Package Managers* |
| 59 |
A candidate Primary Package Manager does aim, or show an aim, at replacing |
| 60 |
the current primary package manager. At a point where the package manager is |
| 61 |
deemed stable a decision must be made whether this package manager should |
| 62 |
become the new primary package manager. At that point the `Primary package |
| 63 |
manager transition phase`_ starts. |
| 64 |
|
| 65 |
*Secondary Package Managers* |
| 66 |
A secondary package manager is a package manager that coexists with the |
| 67 |
primary package manager, while not aiming to replace it. Examples of package |
| 68 |
managers that would fall into this category are: |
| 69 |
|
| 70 |
- Experimental package managers. Package managers whose purpose it is to try |
| 71 |
out new features. |
| 72 |
|
| 73 |
- Focused package managers. For example a package manager that allows the |
| 74 |
use of RPM formatted binary packages would be an example. |
| 75 |
|
| 76 |
- Alternate package managers. Package managers that aim to coexist with the |
| 77 |
primary package manager. They might for example offer a nicer user |
| 78 |
interface than the primary package manager (e.g. show a cow instead of |
| 79 |
compilation messages). |
| 80 |
|
| 81 |
|
| 82 |
*Third Party Package Managers* |
| 83 |
A third party package manager is any package manager that lacks recognition |
| 84 |
from Gentoo as being in any other category. A third party package manager may |
| 85 |
or may not have a Gentoo package, but is not supported beyond that. |
| 86 |
|
| 87 |
|
| 88 |
Package manager requirements |
| 89 |
============================ |
| 90 |
|
| 91 |
As a package manager is in a state of higher support there are higher |
| 92 |
requirements to it. The purpose of these requirements is to ensure the unity of |
| 93 |
the distribution and the package tree. For this purpose it is needed that there |
| 94 |
is only one primary package manager. This is from gentoo's perspective. From a |
| 95 |
user perspective it is perfectly possible to use another package |
| 96 |
manager. Candidate primary package managers and secondary package managers are |
| 97 |
also supported in regards to bugs etc. |
| 98 |
|
| 99 |
|
| 100 |
Primary package manager requirements |
| 101 |
------------------------------------ |
| 102 |
|
| 103 |
The primary package manager is the package manager that sets the standards for |
| 104 |
the tree. All ebuilds in the tree must function with the primary package |
| 105 |
manager. As the primary package manager sets the standard it does not have to |
| 106 |
maintain compatibility with other package managers. This does not mean that the |
| 107 |
actual implementation is the standard, but that the maintainers have the ability |
| 108 |
to define new standards, together with the other involved gentoo projects. |
| 109 |
|
| 110 |
The primary package manager does however have the responsibility that it must be |
| 111 |
very stable. The primary package manager must maintain compatibility with old |
| 112 |
versions of itself for extended periods of time. This compatibility time is set |
| 113 |
by the council. The suggested time would be one year from the point that there |
| 114 |
is a compatible stable version for all supported architectures. |
| 115 |
|
| 116 |
Another compatibility requirement for the primary package manager is a limited |
| 117 |
forward compatibility. It must always be possible to transition from the |
| 118 |
unstable version of the primary package manager to a stable version. This may be |
| 119 |
done either by first introducing reading compatibility for a new format and only |
| 120 |
having write support later. Another way would be the provision of a conversion |
| 121 |
tool that ensures that the on disk information maintained by the package manager |
| 122 |
is supported by the stable package manager. |
| 123 |
|
| 124 |
The primary package manager maintainers further have the responsibility to allow |
| 125 |
competition. This means that reasonable patches from the maintainers of |
| 126 |
secondary or candidate primary package managers must be applied, given that |
| 127 |
these patches are as independent of that package manager as possible. |
| 128 |
|
| 129 |
The primary package manager is maintained on official Gentoo infrastructure, |
| 130 |
under control of Gentoo developers. |
| 131 |
|
| 132 |
|
| 133 |
Candidate primary package manager requirements |
| 134 |
------------------------------------------------ |
| 135 |
|
| 136 |
A candidate primary package manager aims to replace the primary package |
| 137 |
manager. The council is responsible for deciding whether this is done. The |
| 138 |
requirements are there to ensure that it is actually possible to transition a |
| 139 |
candidate primary package manager into the primary package manager. |
| 140 |
|
| 141 |
First of all, there must exist a transition path. This means that the on disk |
| 142 |
data of the primary package manager can be used by (or converted to a format |
| 143 |
usable by) the candidate primary package manager. |
| 144 |
|
| 145 |
Second, there must be a test path. It must be possible for the developers to |
| 146 |
test out the candidate primary package manager on their working systems. This |
| 147 |
means that the transition path must exist. This also means that there are no |
| 148 |
serious obstacles for reverting to the current primary package manager. This |
| 149 |
reverting must also be usable when it is decided that the candidate will not |
| 150 |
become primary package manager, for example because serious design flaws or bugs |
| 151 |
were found. Ideally, the Candidate Primary Package Manager and the Primary |
| 152 |
Package Manager can be installed simultaneously. If not, clear instructions must |
| 153 |
be provided for both ways of transitioning. |
| 154 |
|
| 155 |
Third, there must exist an ebuild test path. It must be possible for package |
| 156 |
managers to test ebuilds in one tree for both the primary as well as the |
| 157 |
candidate primary package manager. It is not an issue if this requires a special |
| 158 |
mode for the candidate primary package manager. It is not an issue either if |
| 159 |
compatibility can be achieved by having the candidate primary package manager |
| 160 |
unmerge the package. |
| 161 |
|
| 162 |
Fourth, there must be support. This means that the package manager is actively |
| 163 |
maintained under control of Gentoo. If it is not maintained on Gentoo |
| 164 |
infrastructure, the means must be there to move the package manager, with its |
| 165 |
change history, to Gentoo infrastructure. This means that it must be maintained |
| 166 |
on a Gentoo supported versioning system, or on a version system whose history |
| 167 |
can be converted to a Gentoo supported versioning system. |
| 168 |
|
| 169 |
Fifth, release capabilities. There must exist automated tools that use the |
| 170 |
candidate primary package manager to create release media that have similar |
| 171 |
capabilities as those released using the old primary package manager. The exact |
| 172 |
requirements are determined by the Release Engineering project, but should not |
| 173 |
be significantly beyond what is currently implemented using the primary package |
| 174 |
manager. |
| 175 |
|
| 176 |
|
| 177 |
Secondary package manager requirements |
| 178 |
-------------------------------------- |
| 179 |
|
| 180 |
A secondary package manager is a package manager that instead of directly aiming |
| 181 |
at replacing the current primary package manager as primary package manager aims |
| 182 |
to cooperate with the primary package manager. As such a secondary package |
| 183 |
manager does not set the standard on the tree, but follows the standard set by |
| 184 |
the primary package manager. |
| 185 |
|
| 186 |
There are two kinds of secondary package managers. The first kind is formed by |
| 187 |
those that do not maintain their own installed package database, but work with |
| 188 |
the package database of the primary package manager. While these package |
| 189 |
managers can put additional information in the database, these entries must |
| 190 |
remain compatible with the primary package managers. Verification, reference, |
| 191 |
and deinstallation by the primary package manager must remain functional. |
| 192 |
|
| 193 |
The second kind is formed by those package managers that maintain their own |
| 194 |
package database, or a package database incompatible with the primary package |
| 195 |
manager. To ensure the secondary role of these package managers the support in |
| 196 |
the tree for these package managers is provided along with restrictions. |
| 197 |
|
| 198 |
The first restriction is that no packages in the tree must rely on the secondary |
| 199 |
package manager. While packages may provide a level of support (while being |
| 200 |
compatible with the primary package manager) this may not result in a |
| 201 |
significant increase of features. If this were allowed, this would mean that |
| 202 |
while they technically work with the primary package manager, there would be |
| 203 |
significant incentive to use the secondary package manager. As the use of this |
| 204 |
secondary package manager disallows the parallel use of the primary package |
| 205 |
manager, this would result in users using the secondary package manager as their |
| 206 |
primary package manager. |
| 207 |
|
| 208 |
Users are allowed to make their own choices. However by making the tree favour a |
| 209 |
package manager that is not the primary package manager, this will lead to the |
| 210 |
secondary package manager becoming the effective primary package manager. As |
| 211 |
this will be a decision by default instead of a conscious choice by the council, |
| 212 |
this is an undesirable result. |
| 213 |
|
| 214 |
There is one exclusion for the restriction of packages that only work with or |
| 215 |
have significant improvements with the secondary package manager. That is |
| 216 |
packages that by their nature are only usable with this secondary package |
| 217 |
manager. An example would be a graphical front-end to the secondary package |
| 218 |
manager. |
| 219 |
|
| 220 |
If a secondary package manager works along the primary package manager, but by |
| 221 |
itself does not have the capabilities of becoming a primary package manager the |
| 222 |
risks of choice by default are lower. As a result, the council could choose to |
| 223 |
allow the inclusion of packages that work only or significantly better with this |
| 224 |
secondary package manager. For example at a point where there is a stable, |
| 225 |
functional, package manager that can handle RPM format packages, the council |
| 226 |
could decide to include these packages directly in the tree, instead of using |
| 227 |
wrapper scripts for those packages that are only provided in the RPM |
| 228 |
format. Such a decision does imply that the maintainers of the primary package |
| 229 |
manager must take this secondary package manager into account. |
| 230 |
|
| 231 |
|
| 232 |
Third party package manager requirements |
| 233 |
---------------------------------------- |
| 234 |
|
| 235 |
A third party package manager is just that. It is a package manager without any |
| 236 |
support within Gentoo. As there is no control by Gentoo over the package manager |
| 237 |
this means that there are no requirements on the package manager. |
| 238 |
|
| 239 |
This complete lack of control however also translates to the fact that Gentoo |
| 240 |
can not make package manager specific changes to support this package |
| 241 |
manager. Package manager specific means that it is possible to request changes |
| 242 |
that make the tree more independent of the primary package manager. These |
| 243 |
changes must however be agnostic of the package manager, and only make it easier |
| 244 |
to have alternative package managers. |
| 245 |
|
| 246 |
|
| 247 |
Transition phases |
| 248 |
================= |
| 249 |
|
| 250 |
Primary package manager transition phase |
| 251 |
---------------------------------------- |
| 252 |
|
| 253 |
A candidate primary package manager can be chosen to become primary package |
| 254 |
manager. This can only happen by council decision. This decision can only be |
| 255 |
made when the candidate primary package manager is stable on all stable |
| 256 |
architectures. (all architectures except experimental ones). There is a |
| 257 |
incubation period of at least 3 months before a candidate primary package |
| 258 |
manager can become the primary package manager. |
| 259 |
|
| 260 |
After the decision has been made to replace the primary package manager, the |
| 261 |
transition phase starts. The use of the old stable package manager must remain |
| 262 |
supported for a period of 6 months. This means that core packages must be |
| 263 |
installable by this package manager. Further the possibility to convert the |
| 264 |
system automatically to the new primary package manager must be available for at |
| 265 |
least 18 months, but preferably longer (enable installing the new package |
| 266 |
manager from the old one). |
| 267 |
|
| 268 |
During the transition phase packages are allowed in the tree that use the new |
| 269 |
features of the new primary package manager. While backward compatibility with |
| 270 |
the previous primary package manager must be maintained a forward compatibility |
| 271 |
is no longer needed. |
| 272 |
|
| 273 |
|
| 274 |
Secondary package manager to candidate primary package manager transition |
| 275 |
------------------------------------------------------------------------- |
| 276 |
|
| 277 |
The transition from secondary package manager to candidate primary package |
| 278 |
manager is straightforward. The secondary package manager must satisfy all |
| 279 |
requirements for a candidate primary package manager. At that point its |
| 280 |
maintainers can announce that they are changing the status to candidate primary |
| 281 |
package manager. This allows a greater support from Gentoo in achieving that |
| 282 |
goal. |
| 283 |
|
| 284 |
|
| 285 |
Third party to other transition |
| 286 |
------------------------------- |
| 287 |
|
| 288 |
When a third party package manager wants to transition into one of the other |
| 289 |
categories (except primary package manager) it must satisfy all requirements for |
| 290 |
that category. |
| 291 |
|
| 292 |
|
| 293 |
References |
| 294 |
========== |
| 295 |
|
| 296 |
.. _paludis: http://paludis.berlios.de/ |
| 297 |
.. _pkgcore: http://gentooexperimental.org/~ferringb/bzr/pkgcore/ |
| 298 |
.. _Open Publication License: http://www.opencontent.org/openpub/ |
| 299 |
|
| 300 |
|
| 301 |
Copyright |
| 302 |
========= |
| 303 |
|
| 304 |
This document is copyright 2006 by Paul de Vrieze and licensed under the |
| 305 |
`Open Publication License`_. |
Parent Directory
| 
Revision Log