Anant Narayanan wrote: > Hi Mike, > > On 31-Mar-07, at 2:21 AM, Mike Frysinger wrote: >> not really, why dont you apply some of your logic: >> - you are not wanted as an official Gentoo developer ... the past >> clearly >> shows this >> - the official package manager of Gentoo would need to be >> completely "in-house" with respect to control, direction, etc... >> - "in-house" would require every one who is control of the package >> manager to >> be a Gentoo developer >> - in order for you to gain @gentoo.org again, we'd need either a >> complete >> flush of developer blood who would accept you or you to change >> yourself ... >> neither of which are realistic >> >> so let's put this all together shall we: >> you are in full control of paludis, you will not be a Gentoo developer, >> thereforce paludis will not be the official Gentoo package manager > > The logic is flawed. I don't understand why Gentoo can't switch to > paludis so long as there are "in-house" Gentoo developers ready to > maintain and support it. > > <snip> >> "emerge" is a brand name for Gentoo and while you can complain about >> lack of >> features all you want, dropping portage and installing a different >> package >> manager with a completely different interface will surely causes a >> huge pita >> for everyone > > It is a rather trivial issue to wrap paludis or pkgcore commands to > their "emerge" equivalents. As discussed before on the thread, mere > command-line compatibility is not an issue at all. If a switch is made > to a new package, I am sure enough steps will be taken to ensure that > the process is as transparent as possible, and most users will not even > notice the difference; except of course the immediate benefits. > > Cheers, > -- > Anant > [EMAIL PROTECTED] mailing list > No one is proposing that Gentoo "switch" to anything at this point.
Speaking from a documentation perspective, it's actually more of a task than you'd think. Command wrappers to emerge etc. are one thing, but the output produced is another. Not to mention the fact that Paludis can't do things that Portage does, and vice versa. It's not a 1:1 drop-in replacement, and no one should say it is. There'd be a helluva lot of documentation to rewrite, for both /doc/en/ (which the GDP oversees) as well as the many docs in the various /proj/ spaces. For the forseeable future, since we can't go on vague statements from either camp of "feature foo will be ready in, oh, about $x releases", Portage is here to stay. It's not being replaced by anything.
signature.asc
Description: OpenPGP digital signature
