Re: [gentoo-dev] GLEP 49 - take 2

[Ned Ludd]

On Mon, 2006-05-22 at 22:51 +0100, Chris Bainbridge wrote:
> On 22/05/06, Ned Ludd <solar@g.o> wrote:
> > On Mon, 2006-05-22 at 10:29 -0500, Grant Goodyear wrote:
> > > I'm not sure I understand why.  After all, mandriva, suse, ubuntu, and
> > > many others have survived quite well.
> >
> > rpm and apt have withstood the test of time and are mature pkg
> > managers, not immature experimental code still in major development.
>
> I don't think anybody is proposing that the alternatives to portage
> are ready now. It is more a matter of principle -


> would you have any
> objection to a mature and stable package manager developed by an
> external entity?

As you did not use the term 'primary' here then absolutely not. I'm all
for innovations, people coding and keeping busy. I have no problems
with secondary pkg mgt system that are hosted off site and maintained
by external forces as long as it's features don't introduce
incompatibilities into our existing tree or put pressure on our 
primary pkg mgt system to match XYZ's features.

However as a member of the existing portage team and also as a council 
member I would reject (and I would encourage[read work really hard at
it] other council members to do the same) any GLEP which allowed or
promoted the primary pkg mgt system being hosted offsite and maintained
by non devs at the juncture in time. I joined our portage team because
I realized that our pkg mgt is not a toy and can't be treated as such.
An external team controlling that I simply do not think work well for
us in terms of the primary pkg mgt system.

> > >  More to the point, though, it's
> > > not clear to me what awful things happen if Gentoo does not own the
> > > package manager code,
> >
> > It should be pretty clear that one of the main problems is letting
> > others decide which features we will and wont have and defining our
> > standards based on their needs and not our own.
>
> As long as the license is open source, Gentoo is free to apply its own
> patches to add features or support different standards before
> redistributing it. If this becomes too onerous, it would be possible
> to fork the external project and bring it under internal control.

Look those projects are forks. We are not the fork and we have a 
functional pkg mgt system at this time so there is no need to 
complicate that. Yes it's a control thing and that control needs to
remain internal period.


> > Please don't forget either that what we know as Gentoo is
> > based/built upon the tool known as portage. Everything we do
> > (all teams included) revolves around it.
>
> If there were an update to portage tomorrow, based on a new
> architecture, which implemented the same command line interfaces, then
> most people wouldn't notice the difference. Decisions should be based
> on an unsentimental evaluation of the merits of each system.
>
> This discussion is reminiscent of the arguments for and against
> relying on bitkeeper for linux development. The difference is that as
> long as the Gentoo project relies on open source, it can never be held
> hostage like the kernel developers were.

That is their own fault for making a bad decisions early on and I don't
see it being all that relevant in the topic of this discussion.

-- 
Ned Ludd <solar@g.o>
Gentoo Linux

-- 
gentoo-dev@g.o mailing list