Seemant Kulleen <[EMAIL PROTECTED]> posted [EMAIL PROTECTED], excerpted below, on Fri, 30 Mar 2007 15:28:52 -0400:
> On Fri, 2007-03-30 at 20:42 +0200, Matthias Langer wrote: > > >> i don't think that personal issues should be taken into account when it >> comes to choosing a new official package manager for gentoo. > > It's relevant in that people have to work with the developers of the > package manager. Unlike most other things in the portage tree, the > package manager ties very closely to the very definition of the > distribution itself. Hence, if people are unable to get along, then by > adopting a package manager like that, you inherently adopt the > developers of that package manager and all the personnel issues that > accompany it. > > Ideally, however, I agree with you that it should be based on technical > merits. The reality is that there are people involved. And people > always complicate things. Your replies always seem so... calm and sane. Thanks. I keep seeing references to an "official" package manager. Clearly, at this point, it's portage, in part because there was no other practical reference for deciding whether the ebuild or the handling of it was broken. If it worked in portage, therefore, by definition, it was fine. (Well, with certain exceptions where portage was held to have bugs, but whether it was a bug in portage or not had to be decided before one could then rule on whether it was a bug in the tree or not.) However, now that PMS is finally about to provide what should be a definitive description of current generation package behavior, with the announced intention to update this with new versions into the future as required, the dependence on portage as the reference will soon be going away. The announced intention for this, among other things, is to allow alternate package managers, such that it can still be clear when it's the package broken and when it's the package manager. So far, so good. However, with such a definitive package behavior reference, the question presents itself, with what looks to be several possible alternatives waiting, why must Gentoo have an "official" package manager at all, and indeed, what purpose, other than name recognition, does maintaining such an "official" manager have? I'd contend that with an appropriate package/tree spec, as soon as we have multiple package managers meeting that spec, then we /don't/ /need/ an "official" package manager. Perhaps one /recommended/ by default in the documentation, sure. Perhaps one that ships on the official Gentoo LiveCD installers, sure. However, all this arguing over "official" package manager is worthless, IMO. Let the alternatives each stand on their own merits, just as we do with all sorts of other choices, optionally with one recommended for newbies who don't have any reason of their own to prefer one over another and likely with one used to build official media, but without any of them recognized as the /official/ package manager, because there's simply no continuing need for such a thing, once the extents and limits of acceptable package behavior at a particular API level has been appropriately speced out. If this approach were taken, it wouldn't have to affect releng much at all, certainly short term, since they could continue using portage, which is assumed to continue to be one of the recognized and accepted alternatives. Longer term, it would only as they found reason to switch to other alternatives, and if they didn't find such reason, well... It would affect bugs very little as well, since there are already bugs where it ends up being a package manager regression, only now, such regressions would be measured against the package spec, rather than against past behavior of any particular package manager (except as necessarily encoded in that spec, for the first version, anyway), and there'd now be a definitive way to say for sure whether it was the package manager or the package. Documentation, there'd necessarily be some adjustment. However, the documentary focus could remain on the "recommended" package manager, referring to the individual manager's documentation if they'd made a choice other than the "recommended" choice. Certainly, it would behoove the maintainers of alternative package managers to create compatible documentation if they wished to go very mainstream, but nothing would force the docs project into massive changes except as such docs were ready and then only in cooperation with the arch teams and releng re the recommendations in the handbook. What about infra? What about Mike's worry of securing Gentoo access to at least one of its package managers? How about this? Maybe it has holes in it, but it should provide at least a minimum security level, and combined with an "open" package manager spec encouraging multiple alternative implementations, I think it's likely to be found workable in practice. Require for any "approved" package manager, not that the working repository /has/ to reside on Gentoo infrastructure, but that a repository mirror, routinely updated every 24 hours at minimum, be maintained on Gentoo infra. For approval, this must be a /complete/ mirror. However, if appropriate and necessary, it may be restricted access. (Hash out the requirement further as necessary, but the idea being that if access is restricted, the council and probably at least one member of Gentoo security must have access.) For approval, the license would be required to be be acceptably open to allow a fork if necessary, and presumably at least one Gentoo developer on the package manager development team wouldbe required as well, with two or more encouraged to prevent issues due to retirements or the like. (If the number of approved package managers should ever exceed three, access and Gentoo dev requirements may be relaxed as found appropriate.) In summary, there would be no "official" Gentoo package manager as such, but ideally, several "approved" managers, plus perhaps some in the community not officially approved. Recommendations would however be allowed, with docs presumably favoring the recommended option, and releng free to use what they felt best in cooperation with the various teams they work with. PM/pkg bug responsibility would be according to the official package spec. Package managers wouldn't be required to be developed on Gentoo infrastructure, but for official approval, if the repository were not on Gentoo infra, a repository mirror on Gentoo infra would be required. If the package manager were independently developed, appropriate licensing and the presence of a Gentoo developer on the package manager development team, thus ensuring continued continuity for Gentoo should the independent project dry up and blow away or the like, would be necessary for approval. Approval requirements may be relaxed to some degree if the number of approved alternatives is found to be enough to eliminate danger of shortage. I'm sure there are holes in the above, there always are in first drafts. However, I just don't see it necessary to squabble over the status of "official" package manager after introduction of a suitable package spec, because I see no reason for there to /be/ such an "official" package manager, but rather a group of "officially approved" managers, given that options exist, with approval contingent on reasonable implementation of the package spec among other things, of course. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman -- gentoo-dev@gentoo.org mailing list
