To set a standard that package managers that seek gentoo project approval and +
To set a standard that package managers that seek Gentoo project approval and support should adhere to.
Currently portage is showing its age. The code of portage does not seem to be -salvageable for new versions. There are two known alternative package managers -that claim a level of portage compatibility. These alternatives are paludis [1] -and pkgcore [2]. Before these alternatives are developed further, a set of rules -should be created to level the playing field and ensuring that decisions can be -made clearly.
+Currently Portage is showing its age. The code of Portage does not seem to be +salvageable for new versions. As of the date of publication, there are two known +alternative package managers that claim a level of Portage compatibility. These +alternatives are paludis [1] and pkgcore [2]. Before these alternatives are +developed further, a set of rules should be created to level the playing field +and ensuring that decisions can be made clearly.
A secondary package manager is a package manager that coexists with the -primary package manager, while not aiming to replace it. Package managers -that would fall into this category are:
+primary package manager, while not aiming to replace it. Examples of package +managers that would fall into this category are:The primary package manager is the package manager that sets the standards for the tree. All ebuilds in the tree must function with the primary package manager. As the primary package manager sets the standard it does not have to maintain compatibility with other package managers.
The primary package manager does however have the responsibility that it must be very stable. The primary package manager must maintain compatibility with old -versions of itself for extended periods of time. This compatibilty time is set +versions of itself for extended periods of time. This compatibility time is set by the council. The suggested time would be one year from the point that there is a compatible stable version for all supported architectures.
-Another compatibilty requirement for the primary package manager is a limited +
Another compatibility requirement for the primary package manager is a limited forward compatibility. It must always be possible to transition from the unstable version of the primary package manager to a stable version. This may be done either by first introducing reading compatibility for a new format and only having write support later. Another way would be the provision of a conversion tool that ensures that the on disk information maintained by the package manager is supported by the stable package manager.
-The primary package manager is maintained on official gentoo infrastructure, -under control of gentoo developers.
+The primary package manager is maintained on official Gentoo infrastructure, +under control of Gentoo developers.
A candidate primary package manager aims to replace the primary package manager. The council is responsible for deciding whether this is done. The requirements are there to ensure that it is actually possible to transition a @@ -173,24 +177,36 @@
Second, there must be a test path. It must be possible for the developers to test out the candidate primary package manager on their working systems. This means that the transition path must exist. This also means that there are no -serious obstacles for reverting to the current primary package manager.
+serious obstacles for reverting to the current primary package manager. This +reverting must also be usable when it is decided that the candidate will not +become primary package manager, for example because serious design flaws or bugs +were found. Ideally, the Candidate Primary Package Manager and the Primary +Package Manager can be installed simultaneously. If not, clear instructions must +be provided for both ways of transitioning.Third, there must exist an ebuild test path. It must be possible for package managers to test ebuilds in one tree for both the primary as well as the candidate primary package manager. It is not an issue if this requires a special mode for the candidate primary package manager. It is not an issue either if -compatibilty can be achieved by unmerging the package in the candidate primary -package manager.
+compatibility can be achieved by having the candidate primary package manager +unmerge the package.Fourth, there must be support. This means that the package manager is actively -maintained under control of gentoo. If it is not maintained on gentoo +maintained under control of Gentoo. If it is not maintained on Gentoo infrastructure, the means must be there to move the package manager, with its -change history, to gentoo infrastructure. This means that it must be maintained -on a gentoo supported versioning system, or on a version system whose history -can be converted to a gentoo supported versioning system.
+change history, to Gentoo infrastructure. This means that it must be maintained +on a Gentoo supported versioning system, or on a version system whose history +can be converted to a Gentoo supported versioning system. +Fifth, release capabilities. There must exist automated tools that use the +candidate primary package manager to create release media that have similar +capabilities as those released using the old primary package manager. The exact +requirements are determined by the Release Engineering project, but should not +be significantly beyond what is currently implemented using the primary package +manager.
A secondary package manager is a package manager that instead of directly aiming -at replacing portage as primary package manager. As such a secondary package +at replacing the current primary package manager as primary package manager aims +to cooperate with the primary package manager. As such a secondary package manager does not set the standard on the tree, but follows the standard set by the primary package manager.
There are two kinds of secondary package managers. The first kind is formed by @@ -206,21 +222,21 @@
The first restriction is that no packages in the tree must rely on the secondary package manager. While packages may provide a level of support (while being compatible with the primary package manager) this may not result in a -significant increase of features. If this were allowed, this would mean that +significant increase of features. If this were allowed, this would mean that while they technically work with the primary package manager, there would be significant incentive to use the secondary package manager. As the use of this -secondary package manager disallows the paralel use of the primary package +secondary package manager disallows the parallel use of the primary package manager, this would result in users using the secondary package manager as their primary package manager.
-Users are allowed to make their own choices. However by making the tree favor a +
Users are allowed to make their own choices. However by making the tree favour a package manager that is not the primary package manager, this will lead to the -secondary package manager becomming the effective primary package manager. As -this will be a decision by default instead of a concious choice by the council, +secondary package manager becoming the effective primary package manager. As +this will be a decision by default instead of a conscious choice by the council, this is an undesirable result.
There is one exclusion for the restriction of packages that only work with or have significant improvements with the secondary package manager. That is packages that by their nature are only usable with this secondary package -manager. An example would be a graphical frontend to the secondary package +manager. An example would be a graphical front-end to the secondary package manager.
If a secondary package manager works along the primary package manager, but by itself does not have the capabilities of becoming a primary package manager the @@ -234,11 +250,11 @@ manager must take this secondary package manager into account.
A third party package manager is just that. It is a package manager without any -support within gentoo. As there is no control by gentoo over the package manager +support within Gentoo. As there is no control by Gentoo over the package manager this means that there are no requirements on the package manager.
-This complete lack of control however also translates to the fact that gentoo +
This complete lack of control however also translates to the fact that Gentoo can not make package manager specific changes to support this package manager. Package manager specific means that it is possible to request changes that make the tree more independent of the primary package manager. These @@ -247,12 +263,12 @@
A candidate primary package manager can be chosen to become primary package manager. This can only happen by council decision. This decision can only be -made when the candiate primary package manager is stable on all stable +made when the candidate primary package manager is stable on all stable architectures. (all architectures except experimental ones).
After the decision has been made to replace the primary package manager, the transition phase starts. The use of the old stable package manager must remain @@ -272,7 +288,7 @@ manager is straightforward. The secondary package manager must satisfy all requirements for a candidate primary package manager. At that point its maintainers can announce that they are changing the status to candidate primary -package manager. This allows a greater support from gentoo in achieving that +package manager. This allows a greater support from Gentoo in achieving that goal.