1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA1 |
3 |
|
4 |
hello; |
5 |
|
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. |
12 |
|
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. |
15 |
|
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. |
21 |
|
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. |
30 |
|
31 |
Well there is my 'users' point of view; |
32 |
|
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 |
36 |
|
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 |
> |
143 |
|
144 |
- -- |
145 |
.Adam Pickett |
146 |
|
147 |
A.M.Pickett.1@×××××.com |
148 |
-----BEGIN PGP SIGNATURE----- |
149 |
Version: GnuPG v1.4.6 (GNU/Linux) |
150 |
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org |
151 |
|
152 |
iD8DBQFGD5VyApBPo0RrzjERAnELAKDKbrGdH5UcmXvq6hsYEsfpdylWnwCgzH7K |
153 |
9StBe0V9EhxmH84D0snX8f0= |
154 |
=CmP1 |
155 |
-----END PGP SIGNATURE----- |
156 |
|
157 |
-- |
158 |
gentoo-dev@g.o mailing list |