[gentoo-dev] Re: [soc] Python bindings for Paludis

[Duncan]

Seemant Kulleen <seemant@g.o> posted
1175282932.5964.9.camel@localhost, 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@g.o mailing list