Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: [soc] Python bindings for Paludis
Date: Sat, 31 Mar 2007 06:15:39
Message-Id: pan.2007.03.31.06.12.08@cox.net
In Reply to: Re: [gentoo-dev] [soc] Python bindings for Paludis by Seemant Kulleen
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

Replies

Subject Author
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis Adam Pickett <a.m.pickett.1@×××××.com>
Re: [gentoo-dev] Re: [soc] Python bindings for Paludis Mike Auty <ikelos@g.o>