1 |
On Friday 30 March 2007, Ciaran McCreesh wrote: |
2 |
> Gentoo's lack of progress is an extremely relevant issue... |
3 |
|
4 |
dont push your own agendas under the guise that Gentoo is lacking progress |
5 |
|
6 |
> > to start with, Paludis will never be an official package manager for |
7 |
> > Gentoo so long as you are heavily involved. now that we've put a |
8 |
> > bolt right between the eyes of that pink elephant, how about we |
9 |
> > address some other things as well ... |
10 |
> |
11 |
> Ah, resorting to ad hominem. Is that the best you can manage? Is the |
12 |
> best excuse you can provide to users for denying them the things they |
13 |
> want and need "waah! ciaranm boogeyman!"? |
14 |
|
15 |
not really, why dont you apply some of your logic: |
16 |
- you are not wanted as an official Gentoo developer ... the past clearly |
17 |
shows this |
18 |
- the official package manager of Gentoo would need to be |
19 |
completely "in-house" with respect to control, direction, etc... |
20 |
- "in-house" would require every one who is control of the package manager to |
21 |
be a Gentoo developer |
22 |
- in order for you to gain @gentoo.org again, we'd need either a complete |
23 |
flush of developer blood who would accept you or you to change yourself ... |
24 |
neither of which are realistic |
25 |
|
26 |
so let's put this all together shall we: |
27 |
you are in full control of paludis, you will not be a Gentoo developer, |
28 |
thereforce paludis will not be the official Gentoo package manager |
29 |
|
30 |
> No no, I'd be quite happy with any package manager that meets my needs |
31 |
> and the needs of other people. Portage is not such a package manager, |
32 |
> and, let's face it, never will be. The continuing delusion that Portage |
33 |
> will somehow magically improve and allow Gentoo to keep up with other |
34 |
> distributions is largely why Gentoo is stuck where it is. |
35 |
|
36 |
there's a magic pill if i ever saw one ... the only available package managers |
37 |
at the moment that satisfy your requirements is paludis ... therefore see |
38 |
previous statements |
39 |
|
40 |
> > a good topic for the next council meeting i think would be to start |
41 |
> > up a spec of requirements that a package manager must satisfy before |
42 |
> > it'd be an official package manager for Gentoo ... off the top of my |
43 |
> > head: |
44 |
> > - the main developers need to be Gentoo developers |
45 |
> > - source code hosted on Gentoo infrastructure |
46 |
> > - compatible "emerge" and "ebuild" binaries |
47 |
> |
48 |
> As you know fine well, the Council has already rejected GLEP 49, which |
49 |
> says more or less that. |
50 |
|
51 |
actually, no, GLEP 49 covers a ton more than what i'm proposing |
52 |
|
53 |
> As you also know fine well, those requirements |
54 |
> mean Gentoo will permanently be stuck with Portage (and when dreaming |
55 |
> up silly and biased requirements, bear in mind that Portage was at one |
56 |
> point close to being moved off Gentoo infrastructure because of the huge |
57 |
> delays in setting up svn...). |
58 |
|
59 |
again, wrong ... read what i said, my requirements would control selection of |
60 |
an official package manager and in fact are quite general and dont really |
61 |
come with restrictions as you seem to think |
62 |
|
63 |
"emerge" is a brand name for Gentoo and while you can complain about lack of |
64 |
features all you want, dropping portage and installing a different package |
65 |
manager with a completely different interface will surely causes a huge pita |
66 |
for everyone |
67 |
|
68 |
nowhere did i say the behavior of portage needs to be retained by a package |
69 |
manager ... i was suggesting that any official Gentoo package manager would |
70 |
have a way for users to continue with the general feel of things so that |
71 |
people can do `emerge foo` and know that the package "foo" would be |
72 |
installed. package managers are free to emulate this however they want and |
73 |
provide whatever other main binary they want. |
74 |
-mike |