Paul de Vrieze wrote:
The promissed glep on package manager requirements. Please comment on it.
There are some parts that may be controversial (portage has in the past not
provided support for reverting to stable either), but please keep the
discussion on topic.
Paul
s/primary/official/g
This primary business is silly IMHO. GCC is Gentoo's official compiler,
baselayout is the "official" init system, etc...
There is precedent here, and you are ignoring it.
Basically this whole GLEP is a reactive farse. I realize thats not your
intention, you seriously want a defined manner in which many package
managers can live. However reading the GLEP it seems to be built
completely against Paludis; stacking the deck as it were. However I
left other comments below ;)
------------------------------------------------------------------------
[Gentoo] <http://www.gentoo.org/> [*Gentoo Linux Home
<http://www.gentoo.org/>*] [*GLEP Index
<http://www.gentoo.org/proj/en/glep>*] [*GLEP Source
<http://www.gentoo.org/proj/en/glep/glep-0049.txt>*]
GLEP: 49
Title: Alternative Package Manager requirements
Version: 2214
Last-Modified: 2006-05-20 14:51:41 +0200 (Sat, 20 May 2006)
<http://www.gentoo.org/cgi-bin/viewcvs.cgi/xml/htdocs/proj/en/glep/glep-0049.txt?cvsroot=gentoo>
Author: Paul de Vrieze <pauldv at gentoo.org>,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst <glep-0002.html>
Created: 18-May-2006
Post-History: 19-May-2006
------------------------------------------------------------------------
Contents
* Abstract <#abstract>
* Motivation <#motivation>
* Rationale <#rationale>
* Backwards Compatibility <#backwards-compatibility>
* Categories of package managers <#categories-of-package-managers>
* Package manager requirements <#package-manager-requirements>
o primary package manager requirements
<#primary-package-manager-requirements>
o candidate primary package manager requirements
<#candidate-primary-package-manager-requirements>
o secondary package manager requirements
<#secondary-package-manager-requirements>
o third party package manager requirements
<#third-party-package-manager-requirements>
* transition phases <#transition-phases>
o primary package manager transition phase
<#primary-package-manager-transition-phase>
o Secondary package manager to candidate primary package
manager transition
<#secondary-package-manager-to-candidate-primary-package-manager-transition>
o Third party to other transition
<#third-party-to-other-transition>
* References <#references>
* Copyright <#copyright>
Abstract <#id7>
This GLEP describes four classes of package managers. What the
requirements for them are, and what support they can receive.
Motivation <#id8>
To set a standard that package managers that seek gentoo project
approval and support should adhere to.
Rationale <#id9>
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 <http://paludis.berlios.de/> [1] <#id1> and
pkgcore <http://gentooexperimental.org/~ferringb/bzr/pkgcore/> [2]
<#id3>. 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.
Backwards Compatibility <#id10>
Not a problem for this GLEP. There is no previous standard as the issue
did not exist before. This GLEP is to prevent future compatibility issues.
If there is Official and 'everything else" I think this whole section
can be dropped.
Categories of package managers <#id11>
We distinguish four categories of package managers. While a package
manager can transition from one category to another, it can not be in
two categories at the same time. It can be in a state of transition though.
/Primary Package Manager/
There is one primary package manager. Currently this position is
held by portage. The primary package manager is assigned by the
council and all packages in the official tree must be installable by
a useable version of the primary package manager.
/Candidate Primary Package Managers/
A candidate Primary Package Manager does aim, or show an aim, at
replacing the current primary package manager. At a point where the
package manager is deemed stable a decision must be made whether
this package manager should become the new primary package manager.
At that point the primary package manager transition phase
<#primary-package-manager-transition-phase> starts.
/Secondary Package Managers/
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:
* Experimental package managers. Package managers whose purpose
it is to try out new features.
* Focussed package managers. For example a package manager that
allows the use of rpm formatted binary packages would be an
example.
/Third Party Package Managers/
A third party package manager is any package manager that lacks
recognition from gentoo as being in any other category. A third
party package manager may or may not have a gentoo package, but is
not supported beyond that.
Package manager requirements <#id12>
As a package manager is in a state of higher support there are higher
requirements to it. The purpose of these requirements is to ensure the
unity of the distribution and the package tree. For this purpose it is
needed that there is only one primary package manager.
One official package manager, but many can be used.
primary package manager requirements <#id13>
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.
This outlook inhibits innovation in the tree. I agree with stephen, in
that the tree should set the standard. If you want a new feature in the
tree, I think a proposal would be good ( not a GLEP necessarily, but a
tree proposal ). I think crap goes in that is not discussed in advance...
One could say, the official package manager sets the standard such that
someone needs to have support in the package manager for it to operate
properly.
However in many industries you find the opposite. First a standard is
set, then a prototype (reference board, whathaveyou) is created, then it
is released for companies to use. Here you want the opposite. The
feature as an idea is created, portage implements it, then the other
package managers copy it? Sounds silly ;)
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 by the council. The suggested time would
be one year from the point that there is a compatible stable version for
all supported architectures.
To be honest even portage never did this. We waited "as long as we felt
necessary" and then broke compat.
Another compatibilty 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.
This has no reasoning behind it, in my eyes.
candidate primary package manager requirements <#id14>
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 candidate primary package manager into the primary package
manager.
First of all, there must exist a transition path. This means that the on
disk data of the primary package manager can be used by (or converted to
a format usable by) the candidate primary package manager.
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.
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.
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 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.
Again I don't see a reason for it to be on Gentoo infra, or even for it
to be managed by Gentoo developers offsite. As long as it's active.
One could say Portage is a bit dormant, sure bugs get fixed
features...take a while, as many people will note :)
secondary package manager requirements <#id15>
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 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 those that do not maintain their own installed package
database, but work with the package database of the primary package
manager. While these package managers can put additional information in
the database, these entries must remain compatible with the primary
package managers. Verification, reference, and deinstallation by the
primary package manager must remain functional.
The second kind is formed by those package managers that maintain their
own package database, or a package database incompatible with the
primary package manager. To ensure the secondary role of these package
managers the support in the tree for these package manager is provided
along with restrictions.
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 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 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 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, 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.
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 risks of choice by default are lower. As a result,
the council could choose to allow the inclusion of packages that work
only or significantly better with this secondary package manager. For
example at a point where there is a stable, functional, package manager
that can handle RPM format packages, the council could decide to include
these packages directly in the tree, instead of using wrapper scripts
for those packages that are only provided in the RPM format. Such a
decision does imply that the maintainers of the primary package manager
must take this secondary package manager into account.
third party package manager requirements <#id16>
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 this means that there are no requirements on the
package manager.
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 changes must however be agnostic of the package
manager, and only make it easier to have alternative package managers.
transition phases <#id17>
primary package manager transition phase <#id18>
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 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 supported for a period of 6 months. This means that core
packages must be installable by this package manager. Further the
possibility to convert the system automatically to the new primary
package manager must be available for at least 18 months, but preferably
longer (enable installing the new package manager from the old one).
During the transition phase packages are allowed in the tree that use
the new features of the new primary package manager. While backward
compatibility with the previous primary package manager must be
maintained a forward compatibility is no longer needed.
Secondary package manager to candidate primary package manager
transition <#id19>
The transition from secondary package manager to candidate primary
package 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 goal.
Third party to other transition <#id20>
When a third party package manager wants to transition into one of the
other categories (except primary package manager) it must satisfy all
requirements for that category.
References <#id21>
[1] <#id2> http://paludis.berlios.de/
[2] <#id4> http://gentooexperimental.org/~ferringb/bzr/pkgcore/
[3] <#id6> http://www.opencontent.org/openpub/
Copyright <#id22>
This document is copyright 2006 by Paul de Vrieze and licensed under the
Open Publication License <http://www.opencontent.org/openpub/> [3] <#id5>.
------------------------------------------------------------------------
View document source <glep-pkg.txt>. Generated on: 2006-05-20 12:51 UTC.
Generated by Docutils <http://docutils.sourceforge.net/> from
reStructuredText <http://docutils.sourceforge.net/rst.html> source.
------------------------------------------------------------------------
GLEP: 49
Title: Alternative Package Manager requirements
Version: $Revision: 2214 $
Last-Modified: $Date: 2006-05-20 14:51:41 +0200 (Sat, 20 May 2006) $
Author: Paul de Vrieze <[EMAIL PROTECTED]>,
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 18-May-2006
Post-History: 19-May-2006
Abstract
========
This GLEP describes four classes of package managers. What the requirements for
them are, and what support they can receive.
Motivation
==========
To set a standard that package managers that seek gentoo project approval and
support should adhere to.
Rationale
=========
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`_
and `pkgcore`_. 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.
Backwards Compatibility
=======================
Not a problem for this GLEP. There is no previous standard as the issue did not
exist before. This GLEP is to prevent future compatibility issues.
Categories of package managers
==============================
We distinguish four categories of package managers. While a package manager can
transition from one category to another, it can not be in two categories at the
same time. It can be in a state of transition though.
*Primary Package Manager*
There is one primary package manager. Currently this position is held by
portage. The primary package manager is assigned by the council and all
packages in the official tree must be installable by a useable version of the
primary package manager.
*Candidate Primary Package Managers*
A candidate Primary Package Manager does aim, or show an aim, at replacing
the current primary package manager. At a point where the package manager is
deemed stable a decision must be made whether this package manager should
become the new primary package manager. At that point the `primary package
manager transition phase`_ starts.
*Secondary Package Managers*
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:
- Experimental package managers. Package managers whose purpose it is to try
out new features.
- Focussed package managers. For example a package manager that allows the
use of rpm formatted binary packages would be an example.
*Third Party Package Managers*
A third party package manager is any package manager that lacks recognition
from gentoo as being in any other category. A third party package manager may
or may not have a gentoo package, but is not supported beyond that.
Package manager requirements
============================
As a package manager is in a state of higher support there are higher
requirements to it. The purpose of these requirements is to ensure the unity of
the distribution and the package tree. For this purpose it is needed that there
is only one primary package manager.
primary package manager requirements
------------------------------------
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
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
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.
candidate primary package manager requirements
------------------------------------------------
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
candidate primary package manager into the primary package manager.
First of all, there must exist a transition path. This means that the on disk
data of the primary package manager can be used by (or converted to a format
usable by) the candidate primary package manager.
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.
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.
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
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.
secondary package manager requirements
--------------------------------------
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
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
those that do not maintain their own installed package database, but work with
the package database of the primary package manager. While these package
managers can put additional information in the database, these entries must
remain compatible with the primary package managers. Verification, reference,
and deinstallation by the primary package manager must remain functional.
The second kind is formed by those package managers that maintain their own
package database, or a package database incompatible with the primary package
manager. To ensure the secondary role of these package managers the support in
the tree for these package manager is provided along with restrictions.
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
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
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
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,
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.
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
risks of choice by default are lower. As a result, the council could choose to
allow the inclusion of packages that work only or significantly better with this
secondary package manager. For example at a point where there is a stable,
functional, package manager that can handle RPM format packages, the council
could decide to include these packages directly in the tree, instead of using
wrapper scripts for those packages that are only provided in the RPM
format. Such a decision does imply that the maintainers of the primary package
manager must take this secondary package manager into account.
third party package manager requirements
----------------------------------------
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
this means that there are no requirements on the package manager.
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
changes must however be agnostic of the package manager, and only make it easier
to have alternative package managers.
transition phases
=================
primary package manager transition phase
----------------------------------------
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
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
supported for a period of 6 months. This means that core packages must be
installable by this package manager. Further the possibility to convert the
system automatically to the new primary package manager must be available for at
least 18 months, but preferably longer (enable installing the new package
manager from the old one).
During the transition phase packages are allowed in the tree that use the new
features of the new primary package manager. While backward compatibility with
the previous primary package manager must be maintained a forward compatibility
is no longer needed.
Secondary package manager to candidate primary package manager transition
-------------------------------------------------------------------------
The transition from secondary package manager to candidate primary package
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
goal.
Third party to other transition
-------------------------------
When a third party package manager wants to transition into one of the other
categories (except primary package manager) it must satisfy all requirements for
that category.
References
==========
.. _paludis: http://paludis.berlios.de/
.. _pkgcore: http://gentooexperimental.org/~ferringb/bzr/pkgcore/
.. _Open Publication License: http://www.opencontent.org/openpub/
Copyright
=========
This document is copyright 2006 by Paul de Vrieze and licensed under the
`Open Publication License`_.
--
gentoo-dev@gentoo.org mailing list
