Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Alec Warner]

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 <pauldv@g.o>,
> 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@g.o mailing list