1 |
Seemant Kulleen <seemant@g.o> posted |
2 |
1175282932.5964.9.camel@localhost, excerpted below, on Fri, 30 Mar 2007 |
3 |
15:28:52 -0400: |
4 |
|
5 |
> On Fri, 2007-03-30 at 20:42 +0200, Matthias Langer wrote: |
6 |
> |
7 |
> |
8 |
>> i don't think that personal issues should be taken into account when it |
9 |
>> comes to choosing a new official package manager for gentoo. |
10 |
> |
11 |
> It's relevant in that people have to work with the developers of the |
12 |
> package manager. Unlike most other things in the portage tree, the |
13 |
> package manager ties very closely to the very definition of the |
14 |
> distribution itself. Hence, if people are unable to get along, then by |
15 |
> adopting a package manager like that, you inherently adopt the |
16 |
> developers of that package manager and all the personnel issues that |
17 |
> accompany it. |
18 |
> |
19 |
> Ideally, however, I agree with you that it should be based on technical |
20 |
> merits. The reality is that there are people involved. And people |
21 |
> always complicate things. |
22 |
|
23 |
Your replies always seem so... calm and sane. Thanks. |
24 |
|
25 |
|
26 |
I keep seeing references to an "official" package manager. Clearly, at |
27 |
this point, it's portage, in part because there was no other practical |
28 |
reference for deciding whether the ebuild or the handling of it was |
29 |
broken. If it worked in portage, therefore, by definition, it was fine. |
30 |
(Well, with certain exceptions where portage was held to have bugs, but |
31 |
whether it was a bug in portage or not had to be decided before one could |
32 |
then rule on whether it was a bug in the tree or not.) |
33 |
|
34 |
However, now that PMS is finally about to provide what should be a |
35 |
definitive description of current generation package behavior, with the |
36 |
announced intention to update this with new versions into the future as |
37 |
required, the dependence on portage as the reference will soon be going |
38 |
away. The announced intention for this, among other things, is to allow |
39 |
alternate package managers, such that it can still be clear when it's the |
40 |
package broken and when it's the package manager. |
41 |
|
42 |
So far, so good. However, with such a definitive package behavior |
43 |
reference, the question presents itself, with what looks to be several |
44 |
possible alternatives waiting, why must Gentoo have an "official" package |
45 |
manager at all, and indeed, what purpose, other than name recognition, |
46 |
does maintaining such an "official" manager have? |
47 |
|
48 |
I'd contend that with an appropriate package/tree spec, as soon as we |
49 |
have multiple package managers meeting that spec, then we /don't/ /need/ |
50 |
an "official" package manager. Perhaps one /recommended/ by default in |
51 |
the documentation, sure. Perhaps one that ships on the official Gentoo |
52 |
LiveCD installers, sure. However, all this arguing over "official" |
53 |
package manager is worthless, IMO. Let the alternatives each stand on |
54 |
their own merits, just as we do with all sorts of other choices, |
55 |
optionally with one recommended for newbies who don't have any reason of |
56 |
their own to prefer one over another and likely with one used to build |
57 |
official media, but without any of them recognized as the /official/ |
58 |
package manager, because there's simply no continuing need for such a |
59 |
thing, once the extents and limits of acceptable package behavior at a |
60 |
particular API level has been appropriately speced out. |
61 |
|
62 |
If this approach were taken, it wouldn't have to affect releng much at |
63 |
all, certainly short term, since they could continue using portage, which |
64 |
is assumed to continue to be one of the recognized and accepted |
65 |
alternatives. Longer term, it would only as they found reason to switch |
66 |
to other alternatives, and if they didn't find such reason, well... It |
67 |
would affect bugs very little as well, since there are already bugs where |
68 |
it ends up being a package manager regression, only now, such regressions |
69 |
would be measured against the package spec, rather than against past |
70 |
behavior of any particular package manager (except as necessarily encoded |
71 |
in that spec, for the first version, anyway), and there'd now be a |
72 |
definitive way to say for sure whether it was the package manager or the |
73 |
package. |
74 |
|
75 |
Documentation, there'd necessarily be some adjustment. However, the |
76 |
documentary focus could remain on the "recommended" package manager, |
77 |
referring to the individual manager's documentation if they'd made a |
78 |
choice other than the "recommended" choice. Certainly, it would behoove |
79 |
the maintainers of alternative package managers to create compatible |
80 |
documentation if they wished to go very mainstream, but nothing would |
81 |
force the docs project into massive changes except as such docs were |
82 |
ready and then only in cooperation with the arch teams and releng re the |
83 |
recommendations in the handbook. |
84 |
|
85 |
What about infra? What about Mike's worry of securing Gentoo access to |
86 |
at least one of its package managers? How about this? Maybe it has |
87 |
holes in it, but it should provide at least a minimum security level, and |
88 |
combined with an "open" package manager spec encouraging multiple |
89 |
alternative implementations, I think it's likely to be found workable in |
90 |
practice. Require for any "approved" package manager, not that the |
91 |
working repository /has/ to reside on Gentoo infrastructure, but that a |
92 |
repository mirror, routinely updated every 24 hours at minimum, be |
93 |
maintained on Gentoo infra. For approval, this must be a /complete/ |
94 |
mirror. However, if appropriate and necessary, it may be restricted |
95 |
access. (Hash out the requirement further as necessary, but the idea |
96 |
being that if access is restricted, the council and probably at least one |
97 |
member of Gentoo security must have access.) For approval, the license |
98 |
would be required to be be acceptably open to allow a fork if necessary, |
99 |
and presumably at least one Gentoo developer on the package manager |
100 |
development team wouldbe required as well, with two or more encouraged to |
101 |
prevent issues due to retirements or the like. (If the number of |
102 |
approved package managers should ever exceed three, access and Gentoo dev |
103 |
requirements may be relaxed as found appropriate.) |
104 |
|
105 |
In summary, there would be no "official" Gentoo package manager as such, |
106 |
but ideally, several "approved" managers, plus perhaps some in the |
107 |
community not officially approved. Recommendations would however be |
108 |
allowed, with docs presumably favoring the recommended option, and releng |
109 |
free to use what they felt best in cooperation with the various teams |
110 |
they work with. PM/pkg bug responsibility would be according to the |
111 |
official package spec. Package managers wouldn't be required to be |
112 |
developed on Gentoo infrastructure, but for official approval, if the |
113 |
repository were not on Gentoo infra, a repository mirror on Gentoo infra |
114 |
would be required. If the package manager were independently developed, |
115 |
appropriate licensing and the presence of a Gentoo developer on the |
116 |
package manager development team, thus ensuring continued continuity for |
117 |
Gentoo should the independent project dry up and blow away or the like, |
118 |
would be necessary for approval. Approval requirements may be relaxed to |
119 |
some degree if the number of approved alternatives is found to be enough |
120 |
to eliminate danger of shortage. |
121 |
|
122 |
I'm sure there are holes in the above, there always are in first drafts. |
123 |
However, I just don't see it necessary to squabble over the status of |
124 |
"official" package manager after introduction of a suitable package spec, |
125 |
because I see no reason for there to /be/ such an "official" package |
126 |
manager, but rather a group of "officially approved" managers, given that |
127 |
options exist, with approval contingent on reasonable implementation of |
128 |
the package spec among other things, of course. |
129 |
|
130 |
-- |
131 |
Duncan - List replies preferred. No HTML msgs. |
132 |
"Every nonfree program has a lord, a master -- |
133 |
and if you use the program, he is your master." Richard Stallman |
134 |
|
135 |
-- |
136 |
gentoo-dev@g.o mailing list |