Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Sunday 21 May 2006 05:44, Brian Harring wrote: So... where's the standard? :) Right, no doc yet that's official, thus at this juncture, what's there now (portage) is the effective standard. Said in the last thread, chunking out a formal EAPI=0 definition from the tree/portage implementation, tiz a good thing. But until that's done (and folks agree it's the standard), portage (primary manager) rules, thus doc it out (as I've suggested to ciaran for the slot value and use/slot dep restrictions he's added) if you're after changing the existing definition. Not saying I like it, but it's the reality of current situation- the intention of the glep is to prevent lock in, and to keep the tree unified in terms of support (avoid fracturing of the env the tree has been written against), either a doc standard is created for EAPI=0, or portage defines the standard (since it's primary). I have just committed my current revision. It includes some things about this. That the standard is not only the implementation, but also guidelines etc. This section is intended to convey that the maintainers of the primary package manager can define (keeping the gentoo processes into account) new extensions to the standard, or a new EAPI=1 version. The process should go like this: 1. Standars are set (by the council or whatever). 2. They are implemented in the official package manager. 3. Other package managers follow suit. Council really shouldn't be involved sans big changes imo, and big changes imo should require gleps (both from an archive standpoint, and from fitting the council in via existing process of gleps). I agree with this. One concern out of all of this is ensuring that their isn't ping/ponging back and forth as to which manager is 'official'; arms race in terms of features supported by each manager is a good thing imo, but need to keep that from causing chaos for devs in terms of changing standards. The point indeed. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpgGaeK6rzWV.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have not read this carefully. There is a lot to work through. At first reading, I like it a lot. Regards, Ferris - -- Ferris McCormick (P44646, MI) [EMAIL PROTECTED] Developer, Gentoo Linux (Devrel, Sparc) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.2-ecc0.1.6 (GNU/Linux) iD8DBQFEbxbHQa6M3+I///cRAo9yAJsEF/hxaLrztTnBlNH6I2ZE/pR5hACghqhY DUyfxAlIDVdWBU70tre3nYg= =tvyX -END PGP SIGNATURE- -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
A secondary package manager is a package manager that instead of directly aiming at replacing portage as primary package manager. What does it do instead? 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. Why can a certain ebuild not DEPEND specifically on a third party package manager? I think you raise some good points in this email, however I think the overall aim is flawed. The package manager should be just as switching as the compiler, the libc, the baselayout, or the kernel. None of these require anywhere near as many hoops to jump through to be supported in gentoo, and they all have their own fixes that need to be made. No changes should be made to the tree which directly impedes the ability of the primary package manager to do its job, but at the same time, no changes should be made which impede other package managers from outperforming the primary package manager. Forcing package managers to stay even with all of portages ideosyncrocies is just holding back new package managers from making progress. On 5/20/06, Paul de Vrieze [EMAIL PROTECTED] 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 -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net 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
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Sat, 20 May 2006 14:54:18 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: *Primary Package Manager* There is one primary package manager. Gentoo has always been about choice, could you explain what is the rationale behind having only one primary package manager? All ebuilds in the tree must function with the primary package manager. I definitely see this is as a requirement. One thing I am wondering is, who is responsible for testing the over 24,000 ebuilds in the tree to make sure that they work with the new package manager? Is it the package manager team, arch teams, package/herd maintainers, arch/herd testers, or others? The primary package manager is maintained on official gentoo infrastructure, under control of gentoo developers. I don't really see this as a requirement. Many Linux distributions use package managers that they don't have direct control over. Ubuntu uses apt, Mandrake uses rpm, etc. ~tcort pgp64t2IttlC2.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
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.
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Saturday 20 May 2006 15:47, Dan Meltzer wrote: A secondary package manager is a package manager that instead of directly aiming at replacing portage as primary package manager. What does it do instead? I've just committed a new revision, but it cooperates. A slip up on my part. 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. Why can a certain ebuild not DEPEND specifically on a third party package manager? Basically if an official ebuild requires a third party package manager, this means that gentoo has a requirement on that package manager. If such a package manager at the same time offers support for all packages that the primary package manager supports, this means that in fact users will consider this secondary package manager to be their primary package manager. This leads to a decision by default as the council can at such a point only rubber stamp things. My aim is to make things such that the council can still make a real decision. I think you raise some good points in this email, however I think the overall aim is flawed. The package manager should be just as switching as the compiler, the libc, the baselayout, or the kernel. None of these require anywhere near as many hoops to jump through to be supported in gentoo, and they all have their own fixes that need to be made. No changes should be made to the tree which directly impedes the ability of the primary package manager to do its job, but at the same time, no changes should be made which impede other package managers from outperforming the primary package manager. Forcing package managers to stay even with all of portages ideosyncrocies is just holding back new package managers from making progress. A package manager is not a compiler. To put it in a compiler setting, imagine that only a C or a C++ compiler can be installed at one point. The primary compiler for all files is C. At some point someone comes around and says. I've got this very nice compiler and it uses the C++ language that is more or less compatible with C. Then some code maintainers run of and use all the additional features of C++. If this code is then to be a consistent whole, this means that all code must be compiled with this C++ compiler. In effect replacing C as default language by C++. It is very hard to revert back to C from C++. The leaders of the group had no say in whether it was good to go to C++ (maybe the compilation time is a serious issue), but have to accept it at this point because keeping the old C compiler is a race long lost. -- I do not think that alternative package managers should be limited in what they do. What I think is that their additional features should not be used in the official tree (overlays is another point) to avoid the situation where the council can no longer make the decision to go for the better package manager. There are many changes that can be made without hitting this problem. Multilib systems can work in such a way that portage just sees it as one package while the multilib package manager knows that it is a package consisting of 3 parts (32bit part, shared part, and 64 bit part). It is also possible to have a functionally equivalent package database that has a higher speed, or no longer needs a cache, than the portage compatible one. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpJzZ0bXo3Kp.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Saturday 20 May 2006 11:51, Thomas Cort wrote: On Sat, 20 May 2006 14:54:18 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: *Primary Package Manager* There is one primary package manager. Gentoo has always been about choice, could you explain what is the rationale behind having only one primary package manager? Ok, I'll go along the various situations with two primary package managers that can exist (it has to do with network effects): - There are two primary package managers, A and B. Package manager B accepts ebuilds that package manager A does not accept. At this point package manager B is the most useful. As there is no problem with using package manager B, all authors who need package manager B features use it. They forget about package manager A. As a result, it will not be long before a significant part of the tree does no longer work with package manager A. It is only a matter of time before the (often highly complex, and in need of such features) core packages that everyone needs is in this set. Effectively obsoleting package manager A. - There are two primary package managers, C and D. Each one supports features the other one doesn't. While this situation seems different, it actually isn't that different. In the beginning they each have 50% of the packages that are not usable by both. At some point this 50% will change. At that time ebuild authors have to choose when they need a new feature. In most cases they will choose for that package manager (D) that is used by most people. This increases the incentives for users to use package manager D. This again leads more ebuild authors into using package manager D, etc. Again leading to one package manager to be obsoleted. The situations described above are what is called a network effect. They show why everyone uses internet instead of some people using compuserve, some people america online, some people internet, and yet some other people still using bbs systems. It also explains why windows is by nature a monopoly and why linux has such problems being an alternative operating system (see the interaction between features, compatibility and amount of users). All ebuilds in the tree must function with the primary package manager. I definitely see this is as a requirement. One thing I am wondering is, who is responsible for testing the over 24,000 ebuilds in the tree to make sure that they work with the new package manager? Is it the package manager team, arch teams, package/herd maintainers, arch/herd testers, or others? The other package manager team is responsible for initial testing. At a point where a package manager is accepted as candidate replacement or secondary package manager, it is acceptable that bugs are filed against packages that do not work with the other package manager. If they are caused by the standard (written standard, not things that are accepted by the primary by accident) not being accepted by the secondary or candidate replacement package manager this is a bug on that package manager, otherwise on the violating package. For a secondary package manager this only, when its usage makes sense on the package in the first place. The primary package manager is maintained on official gentoo infrastructure, under control of gentoo developers. I don't really see this as a requirement. Many Linux distributions use package managers that they don't have direct control over. Ubuntu uses apt, Mandrake uses rpm, etc. Those are binary distributions. Even they have extensions in their own package managers. Binary distribution is easier than from source. One of the strengths of Gentoo is formed by the package manager. If the package manager is out of control of gentoo, this means that Gentoo no longer has control over its future or its features. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpyE9SbwJp4b.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
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
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Sat, 20 May 2006 15:41:37 +0100 Stephen Bennett [EMAIL PROTECTED] wrote: 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. Full ACK on this one, though EAPI itself is insufficient, it would only define the ebuild format, but you also have to look at the repo itself (see past -portage-dev discussions about this), e.g. for the Manifest or profile formats. It's not that easy to conform to a spec that doesn't really exist (unless you consider the implementation as spec). Marius -- Public Key at http://www.genone.de/info/gpg-key.pub In the beginning, there was nothing. And God said, 'Let there be Light.' And there was still nothing, but you could see a bit better. signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Saturday 20 May 2006 19:45, Marius Mauch wrote: On Sat, 20 May 2006 15:41:37 +0100 Stephen Bennett [EMAIL PROTECTED] wrote: 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. Full ACK on this one, though EAPI itself is insufficient, it would only define the ebuild format, but you also have to look at the repo itself (see past -portage-dev discussions about this), e.g. for the Manifest or profile formats. It's not that easy to conform to a spec that doesn't really exist (unless you consider the implementation as spec). I have no problem with this. In principle it is unavoidable that a package manager deviates in certain points with the actual standard. This is already true for portage. While there is no formal standard, a partial description can be found in the various authoring guides. The point of the part in the glep is more to say that the maintainers of the primary package manager have control over the format. I will add text to this effect to the GLEP. Paul -- Paul de Vrieze Gentoo Developer Mail: [EMAIL PROTECTED] Homepage: http://www.devrieze.net pgpnVVa4IO6v7.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Saturday 20 May 2006 18:00, Alec Warner wrote: 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 might be multiple official package manager. Only one has the lead position from a gentoo point of view. Please also be aware that the term primary is from the point of view of gentoo, not from user point of view. This GLEP does not mean that there can not be multiple package managers that could play the role of primary package manager for a system. 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 ;) I am not against paludis at all. I want to set the playing field on which alternate package managers can thrive. This way there would be a way in which package managers can live along eachother and better gentoo. I realise this should have been written earlier, preventing wasted efforts, and I am sorry I did not do it before. On design quality I'd like to say that design quality is not only formed by how well the design is on itself. It is even much more how well a system fits in its environment. Ignoring what is already there is the easy way out. A way in which a transition can be made without breaking what is there, and still ensuring a good design after the transition. That is really great design. I'll react on your comments below. 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. The thing is that there are possibilities in between them. They might not be used, but we owe it to current and future package manager designers to allow this possibility. A secondary package manager that installs rpm packages (perhaps for LSB compatibility) can very well be official, but not even able to set the standard on packages (hell it uses rpm's). cut 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. Certainly true. I've added something to this extend to the next revision. 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. Look at this way. It is only a standard when it is supported in a testing version of the primary package manager. 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 ;) Package managers may implement anything they want. Packages (not package managers) may only use it when the primary package manager supports it. I have got clarified it in the new revision that not only the implementation determines the standard, but also the existing guidelines, qa tools, etc. As example paludis would be perfectly right in not supporting all kinds of toplevel magic. Even though portage will not complain it is accepted as something that must not be done. 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
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Sat, 20 May 2006 17:11:57 +0200 Paul de Vrieze [EMAIL PROTECTED] wrote: The primary package manager is maintained on official gentoo infrastructure, under control of gentoo developers. I don't really see this as a requirement. Many Linux distributions use package managers that they don't have direct control over. Ubuntu uses apt, Mandrake uses rpm, etc. Those are binary distributions. Even they have extensions in their own package managers. Binary distribution is easier than from source. One of the strengths of Gentoo is formed by the package manager. If the package manager is out of control of gentoo, this means that Gentoo no longer has control over its future or its features. I definitely agree that Gentoo needs a team of people to deal with the primary package manager, it is one of the most important tools in a Linux system. It is especially important in Gentoo where the package manager is, at this point in time, required to install a standard desktop system. I disagree that the package manager needs to be directly maintained by Gentoo. Since Gentoo will never depend upon a piece of non-Free software[1], it is safe to assume that the package manager is Free software (aka open source). Because of this, we will never be locked-in, helpless, or under the control of an external project. If we dislike the direction in which it is going or want to add our own features, then we are free to do so either by submitting patches upstream, adding our own custom gentoo patches to the stock sources, or by forking the project entirely. So what I suggest is the following: While it is desirable that the primary package manager be maintained on official gentoo infrastructure, under the control of gentoo developers, it is not required. During the path to becoming the primary package manager, the package manager maintainers must be asked if they would like their project to be an official Gentoo project. The package manager maintainers have the right to refuse such an offer if there is a team of at least 3 Gentoo developers that understand the package manager source code and are willing to deal with bugs, testing, feature enhancements, modifications, and integration. I hope the above is an acceptable compromise. It aims at making the project an official Gentoo project while still allowing package managers that aren't under Gentoo's direct control. In that case there are still Gentoo developers who have a handle on the code and can make any modifications / enhancements / feature changes that are required by Gentoo. [1] http://www.gentoo.org/main/en/contract.xml pgpMG26YbC1mC.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
Just two points: - standards should not be set by the primary package manager - the primary package manager does not have to be developed by Gentoo. More about it below: maillog: 20/05/2006-14:54:18(+0200): Paul de Vrieze types 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. I pesonally hate the way this sounds. It implies that the package manager comes before the standards while it should be the other way around. Plus, it would not solve the main problem -- that there are no set standards for the tree. You accept the GLEP like this and there will continue to be no standards. The process should go like this: 1. Standars are set (by the council or whatever). 2. They are implemented in the official package manager. 3. Other package managers follow suit. Take the application servers as a good example. You have Java Servlet Technology, and JavaServer Pages Technology. So far, so good. These are developed by Sun. And you also have Apache Tomcat which is the official reference implementation. So you have the standards set by Sun, and you have an open community implementing them in the official container *later*. And pay attention that these are not maintained by the same organization. And what about the web. You have the W3C that sets the standards for web pages. And you have no single browser to implement them all. So, in order for a package manager to be recognized by Gentoo it should not implement *all* standards. I.e. if you have news delivered with the tree, you could support a package manager that cannot read the news as primary. After all this is not a major feature and does not contradict All ebuilds should work with the primary package manager. And you can have a separate news reader the cooperates with the primary package manager or not. -- \Georgi Georgiev \ Ignorance is when you don't know anything \ / [EMAIL PROTECTED]/ and somebody finds it out. / \ http://www.gg3.net/ \ \ pgpaPJU9FXtoj.pgp Description: PGP signature
Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements
On Sun, May 21, 2006 at 12:10:40PM +0900, Georgi Georgiev wrote: Just two points: - standards should not be set by the primary package manager - the primary package manager does not have to be developed by Gentoo. More about it below: maillog: 20/05/2006-14:54:18(+0200): Paul de Vrieze types 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. I personally hate the way this sounds. It implies that the package manager comes before the standards while it should be the other way around. Plus, it would not solve the main problem -- that there are no set standards for the tree. You accept the GLEP like this and there will continue to be no standards. snipping lots of good reasons about why implementation should not define standards So... where's the standard? :) Right, no doc yet that's official, thus at this juncture, what's there now (portage) is the effective standard. Said in the last thread, chunking out a formal EAPI=0 definition from the tree/portage implementation, tiz a good thing. But until that's done (and folks agree it's the standard), portage (primary manager) rules, thus doc it out (as I've suggested to ciaran for the slot value and use/slot dep restrictions he's added) if you're after changing the existing definition. Not saying I like it, but it's the reality of current situation- the intention of the glep is to prevent lock in, and to keep the tree unified in terms of support (avoid fracturing of the env the tree has been written against), either a doc standard is created for EAPI=0, or portage defines the standard (since it's primary). The process should go like this: 1. Standars are set (by the council or whatever). 2. They are implemented in the official package manager. 3. Other package managers follow suit. Council really shouldn't be involved sans big changes imo, and big changes imo should require gleps (both from an archive standpoint, and from fitting the council in via existing process of gleps). One concern out of all of this is ensuring that their isn't ping/ponging back and forth as to which manager is 'official'; arms race in terms of features supported by each manager is a good thing imo, but need to keep that from causing chaos for devs in terms of changing standards. ~harring pgpa1x9wBpjMZ.pgp Description: PGP signature
