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 <[EMAIL PROTECTED]> 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@gentoo.org mailing list
