| 1 |
Anant Narayanan wrote: |
| 2 |
> Hi Mike, |
| 3 |
> |
| 4 |
> On 31-Mar-07, at 2:21 AM, Mike Frysinger wrote: |
| 5 |
>> not really, why dont you apply some of your logic: |
| 6 |
>> - you are not wanted as an official Gentoo developer ... the past |
| 7 |
>> clearly |
| 8 |
>> shows this |
| 9 |
>> - the official package manager of Gentoo would need to be |
| 10 |
>> completely "in-house" with respect to control, direction, etc... |
| 11 |
>> - "in-house" would require every one who is control of the package |
| 12 |
>> manager to |
| 13 |
>> be a Gentoo developer |
| 14 |
>> - in order for you to gain @gentoo.org again, we'd need either a |
| 15 |
>> complete |
| 16 |
>> flush of developer blood who would accept you or you to change |
| 17 |
>> yourself ... |
| 18 |
>> neither of which are realistic |
| 19 |
>> |
| 20 |
>> so let's put this all together shall we: |
| 21 |
>> you are in full control of paludis, you will not be a Gentoo developer, |
| 22 |
>> thereforce paludis will not be the official Gentoo package manager |
| 23 |
> |
| 24 |
> The logic is flawed. I don't understand why Gentoo can't switch to |
| 25 |
> paludis so long as there are "in-house" Gentoo developers ready to |
| 26 |
> maintain and support it. |
| 27 |
> |
| 28 |
> <snip> |
| 29 |
>> "emerge" is a brand name for Gentoo and while you can complain about |
| 30 |
>> lack of |
| 31 |
>> features all you want, dropping portage and installing a different |
| 32 |
>> package |
| 33 |
>> manager with a completely different interface will surely causes a |
| 34 |
>> huge pita |
| 35 |
>> for everyone |
| 36 |
> |
| 37 |
> It is a rather trivial issue to wrap paludis or pkgcore commands to |
| 38 |
> their "emerge" equivalents. As discussed before on the thread, mere |
| 39 |
> command-line compatibility is not an issue at all. If a switch is made |
| 40 |
> to a new package, I am sure enough steps will be taken to ensure that |
| 41 |
> the process is as transparent as possible, and most users will not even |
| 42 |
> notice the difference; except of course the immediate benefits. |
| 43 |
> |
| 44 |
> Cheers, |
| 45 |
> -- |
| 46 |
> Anant |
| 47 |
> --gentoo-dev@g.o mailing list |
| 48 |
> |
| 49 |
No one is proposing that Gentoo "switch" to anything at this point. |
| 50 |
|
| 51 |
Speaking from a documentation perspective, it's actually more of a task |
| 52 |
than you'd think. Command wrappers to emerge etc. are one thing, but the |
| 53 |
output produced is another. Not to mention the fact that Paludis can't |
| 54 |
do things that Portage does, and vice versa. It's not a 1:1 drop-in |
| 55 |
replacement, and no one should say it is. |
| 56 |
|
| 57 |
There'd be a helluva lot of documentation to rewrite, for both /doc/en/ |
| 58 |
(which the GDP oversees) as well as the many docs in the various /proj/ |
| 59 |
spaces. |
| 60 |
|
| 61 |
For the forseeable future, since we can't go on vague statements from |
| 62 |
either camp of "feature foo will be ready in, oh, about $x releases", |
| 63 |
Portage is here to stay. It's not being replaced by anything. |
Archives