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

[Stephen Bennett]

I agree with the basic intent here, but remain unconvinced that this is
the best way to solve the problems at hand. See below for comments on
particular parts, and for what I believe could be a more elegant
solution. It's not a complete proposal and will be rather rough around
the edges, being more of a brain dump at the moment, but as far as I
can see it addresses all the issues that need to be.


On Sat, 20 May 2006 14:54:18 +0200
Paul de Vrieze <pauldv@g.o> wrote:

> 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.

There's a strong argument for saying that converting Portage to fit
the proposed standards for a primary package manager is a backwards
compaibility consideration. Or, with my below suggestion, making sure
that all existing ebuilds conform to the formalised ebuild
specification.

> 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 current 'Portage defines the tree format' is IMO a cause of a lot
of problems at the moment. It would be better, I think, to define in a
package-manager-agnostic document just what the current ebuild format
(EAPI 0) means. If at any point in the future the primary package
manager changes in what it supports and/or requires, a new EAPI spec is
written. The council, or some other body, can then define which EAPI
formats may be used by ebuilds in the tree.

> The primary package manager is maintained on official gentoo
> infrastructure, under control of gentoo developers.

Reasoning behind this requirement? I can understand the sentiment, but
if gentoo developers have a sufficient degree of control over the
codebase, does it matter where it is hosted? If the worst comes to the
worst, require that any supported package manager be licensed under
GPL-2 and a group of Gentoo developers can simply pick up the latest
version available and fork if it is required. 


> 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.

To throw out a potentially controversial question: is there any reason
behind the implicit assumption that there can only be one fully
supported primary package manager? If, as I suggested above, the ebuild
format and environment is formally defined in such a manner, it should
be entirely possible to support two or more alternative package
managers. Currently this would be impractical at best because of the
possibility of ebuilds working with one and not the other, but with a
formal specification of the ebuild environment it becomes possible to
define in such a case whether it is a package manager bug or whether
the ebuild is making assumptions that are not valid according to the
specification.

> 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.

This requirement seems perfectly reasonable.

> 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.

It strikes me that this, as well as the next requirement, can easily be
achieved by chrooting, regardless of any compatibility or lack thereof
between the two package managers.

> 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.

Define "under control of gentoo". Also see above comment regarding
Gentoo infrastructure.

> 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.

Can't follow the meaning in the first sentence. As for the second, see
above re: defining the ebuild format.

> 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.

And again, see above.

> 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.

Ditto.


> transition phases
> =================
>
> primary package manager transition phase
> ----------------------------------------

Given comments above, this section loses most of its meaning if the
distinction between primary, candidate primary, and secondary is
removed or reduced. Better, I think, to define properly what the
various EAPI values mean in terms of environment and format, and which
values are acceptable for use in the gentoo-x86 tree. At that point,
the primary package manager simply becomes that which is installed by
default and used to build the official release media. It also becomes
possible to support more than one primary package manager. Any concerns
about one package manager taking over 'by default' can be addressed by
letting the council decide which EAPI values are acceptable -- if they
favour one in particular then the list will presumably be the list of
values supported by that package manager.

This alternative approach would provide the ability to enforce a
single primary package manager as defined in your GLEP should it be
thought desirable, but also provides much more flexibility in
supporting more than one. It also reduces the barrier of entry for a
package manager to be supported, since instead of defining the ebuild
format it must only support a format defined elsewhere, there is not
the same requirement for gentoo control -- rather than needing the
single primary package manager to be developed on Gentoo
infrastructure, the same requirements can be achieved by specifying
that there must be at least one package manager supporting the complete
list of current ebuild formats, developed by Gentoo developers on
Gentoo infrastructure. For a package manager to be supported under this
scheme, the requirements would be much the same as for, say, toolchain
packages -- the ebuild must be maintained, and it must be possible to
fix at short notice any bugs in it that prevent it from working with
any of the defined ebuild formats. This can be achieved in the same way
that bugs in any other package are handled -- by fixing upstream,
introducing patches in the ebuild, or a combination of the two.
Obviously a cooperative upstream is greatly beneficial, but it no
longer becomes an absolute requirement. Obviously the ability to
migrate between package managers would be beneficial, but it no longer
becomes such a key requirement.

This approach would be a significant departure from the way we have
traditionally done things, but as you say, Portage is showing its age,
and I believe that this would provide the most flexible, scalable
approach to allow it to be replaced or improved upon.

Comments?
-- 
gentoo-dev@g.o mailing list