Gentoo Archives: gentoo-dev

From: Adam Pickett <a.m.pickett.1@×××××.com>
To: gentoo-dev@l.g.o
Subject: Re: [gentoo-dev] Re: [soc] Python bindings for Paludis
Date: Sun, 01 Apr 2007 11:25:47
In Reply to: [gentoo-dev] Re: [soc] Python bindings for Paludis by Duncan <>
2 Hash: SHA1
4 hello;
6 I'm just a gentoo user who has been lurking for a while trying to find
7 a useful way to help my linux distro. Gentoo was recommended to be as a
8 good way to get into linux and to rapidly understand the difference
9 between the way linux works and windows works.
10 I have to say that for the two years of my university life that i have
11 used Gentoo for it has taught my a lot.
13 Now i have never had a problem with portage my self, but since this
14 thread is in existence there are some definite issues.
16 Myself as a user would very much have to support Duncan's post below and
17 as a Computer Science grad would have to say that it makes sense to
18 clearly define a PMS which should be swappable 1:1 with any other PMS.
19 To help new users the basic command set should also be the same, tho of
20 course each PMS can have its own advanced features.
22 Finally my own personal view of this matter; Gentoo should have and
23 support its own package manager, it makes sense since one of the key
24 advantages of Gentoo is to just have to packages you need with just to
25 support you need i.e. USE flags. Since this is a key goal of the gentoo
26 project it makes sense to provide a 'default' PM which abides to the
27 PMS. It also means that there will always be a secure, monitored,
28 distribution maintained package manager which would guarantee the
29 distributions basic functionality.
31 Well there is my 'users' point of view;
33 As a quick aside, could someone point me in the right direction to help
34 out with Gentoo, I've got some skills in C and C++ tho my main language
35 is Java, but I'm a quick learner :P
37 Duncan wrote:
38 >
39 > I keep seeing references to an "official" package manager. Clearly, at
40 > this point, it's portage, in part because there was no other practical
41 > reference for deciding whether the ebuild or the handling of it was
42 > broken. If it worked in portage, therefore, by definition, it was fine.
43 > (Well, with certain exceptions where portage was held to have bugs, but
44 > whether it was a bug in portage or not had to be decided before one could
45 > then rule on whether it was a bug in the tree or not.)
46 >
47 > However, now that PMS is finally about to provide what should be a
48 > definitive description of current generation package behavior, with the
49 > announced intention to update this with new versions into the future as
50 > required, the dependence on portage as the reference will soon be going
51 > away. The announced intention for this, among other things, is to allow
52 > alternate package managers, such that it can still be clear when it's the
53 > package broken and when it's the package manager.
54 >
55 > So far, so good. However, with such a definitive package behavior
56 > reference, the question presents itself, with what looks to be several
57 > possible alternatives waiting, why must Gentoo have an "official" package
58 > manager at all, and indeed, what purpose, other than name recognition,
59 > does maintaining such an "official" manager have?
60 >
61 > I'd contend that with an appropriate package/tree spec, as soon as we
62 > have multiple package managers meeting that spec, then we /don't/ /need/
63 > an "official" package manager. Perhaps one /recommended/ by default in
64 > the documentation, sure. Perhaps one that ships on the official Gentoo
65 > LiveCD installers, sure. However, all this arguing over "official"
66 > package manager is worthless, IMO. Let the alternatives each stand on
67 > their own merits, just as we do with all sorts of other choices,
68 > optionally with one recommended for newbies who don't have any reason of
69 > their own to prefer one over another and likely with one used to build
70 > official media, but without any of them recognized as the /official/
71 > package manager, because there's simply no continuing need for such a
72 > thing, once the extents and limits of acceptable package behavior at a
73 > particular API level has been appropriately speced out.
74 >
75 > If this approach were taken, it wouldn't have to affect releng much at
76 > all, certainly short term, since they could continue using portage, which
77 > is assumed to continue to be one of the recognized and accepted
78 > alternatives. Longer term, it would only as they found reason to switch
79 > to other alternatives, and if they didn't find such reason, well... It
80 > would affect bugs very little as well, since there are already bugs where
81 > it ends up being a package manager regression, only now, such regressions
82 > would be measured against the package spec, rather than against past
83 > behavior of any particular package manager (except as necessarily encoded
84 > in that spec, for the first version, anyway), and there'd now be a
85 > definitive way to say for sure whether it was the package manager or the
86 > package.
87 >
88 > Documentation, there'd necessarily be some adjustment. However, the
89 > documentary focus could remain on the "recommended" package manager,
90 > referring to the individual manager's documentation if they'd made a
91 > choice other than the "recommended" choice. Certainly, it would behoove
92 > the maintainers of alternative package managers to create compatible
93 > documentation if they wished to go very mainstream, but nothing would
94 > force the docs project into massive changes except as such docs were
95 > ready and then only in cooperation with the arch teams and releng re the
96 > recommendations in the handbook.
97 >
98 > What about infra? What about Mike's worry of securing Gentoo access to
99 > at least one of its package managers? How about this? Maybe it has
100 > holes in it, but it should provide at least a minimum security level, and
101 > combined with an "open" package manager spec encouraging multiple
102 > alternative implementations, I think it's likely to be found workable in
103 > practice. Require for any "approved" package manager, not that the
104 > working repository /has/ to reside on Gentoo infrastructure, but that a
105 > repository mirror, routinely updated every 24 hours at minimum, be
106 > maintained on Gentoo infra. For approval, this must be a /complete/
107 > mirror. However, if appropriate and necessary, it may be restricted
108 > access. (Hash out the requirement further as necessary, but the idea
109 > being that if access is restricted, the council and probably at least one
110 > member of Gentoo security must have access.) For approval, the license
111 > would be required to be be acceptably open to allow a fork if necessary,
112 > and presumably at least one Gentoo developer on the package manager
113 > development team wouldbe required as well, with two or more encouraged to
114 > prevent issues due to retirements or the like. (If the number of
115 > approved package managers should ever exceed three, access and Gentoo dev
116 > requirements may be relaxed as found appropriate.)
117 >
118 > In summary, there would be no "official" Gentoo package manager as such,
119 > but ideally, several "approved" managers, plus perhaps some in the
120 > community not officially approved. Recommendations would however be
121 > allowed, with docs presumably favoring the recommended option, and releng
122 > free to use what they felt best in cooperation with the various teams
123 > they work with. PM/pkg bug responsibility would be according to the
124 > official package spec. Package managers wouldn't be required to be
125 > developed on Gentoo infrastructure, but for official approval, if the
126 > repository were not on Gentoo infra, a repository mirror on Gentoo infra
127 > would be required. If the package manager were independently developed,
128 > appropriate licensing and the presence of a Gentoo developer on the
129 > package manager development team, thus ensuring continued continuity for
130 > Gentoo should the independent project dry up and blow away or the like,
131 > would be necessary for approval. Approval requirements may be relaxed to
132 > some degree if the number of approved alternatives is found to be enough
133 > to eliminate danger of shortage.
134 >
135 > I'm sure there are holes in the above, there always are in first drafts.
136 > However, I just don't see it necessary to squabble over the status of
137 > "official" package manager after introduction of a suitable package spec,
138 > because I see no reason for there to /be/ such an "official" package
139 > manager, but rather a group of "officially approved" managers, given that
140 > options exist, with approval contingent on reasonable implementation of
141 > the package spec among other things, of course.
142 >
144 - --
145 .Adam Pickett
147 A.M.Pickett.1@×××××.com
149 Version: GnuPG v1.4.6 (GNU/Linux)
150 Comment: Using GnuPG with Mozilla -
152 iD8DBQFGD5VyApBPo0RrzjERAnELAKDKbrGdH5UcmXvq6hsYEsfpdylWnwCgzH7K
153 9StBe0V9EhxmH84D0snX8f0=
154 =CmP1
155 -----END PGP SIGNATURE-----
157 --
158 gentoo-dev@g.o mailing list