Re: [gentoo-dev] RFC: GLEP 49 - Package manager requirements

[Paul de Vrieze]

On Saturday 20 May 2006 15:47, Dan Meltzer wrote:
> >A secondary package manager is a package manager that instead of directly
> >aiming at replacing  portage as  primary package manager.
>
> What does it do instead?

I've just committed a new revision, but it cooperates. A slip up on my part.

> >The first restriction is that no packages in the tree must rely on the
> >secondary package  manager. While packages  may provide  a level  of
> >support (while being compatible  with  the  primary  package  manager)
> >this  may  not result  in  a significant increase  of features.
>
> Why can a certain ebuild not DEPEND specifically on a third party
> package manager?

Basically if an official ebuild requires a third party package manager, this 
means that gentoo has a requirement on that package manager. If such a 
package manager at the same time offers support for all packages that the 
primary package manager supports, this means that in fact users will consider 
this secondary package manager to be their primary package manager. This 
leads to a decision by default as the council can at such a point only rubber 
stamp things. My aim is to make things such that the council can still make a 
real decision.

> I think you raise some good points in this email, however I think the
> overall aim is flawed.  The package manager should be just as
> switching as the compiler, the libc, the baselayout, or the kernel.
> None of these require anywhere near as many hoops to jump through to
> be supported in gentoo, and they all have their own fixes that need to
> be made.  No changes should be made to the tree which directly impedes
> the ability of the "primary package manager" to do its job, but at the
> same time, no changes should be made which impede other package
> managers from outperforming the "primary package manager".  Forcing
> package managers to stay even with all of portages ideosyncrocies is
> just holding back new package managers from making progress.

A package manager is not a compiler. To put it in a compiler setting, imagine 
that only a C or a C++ compiler can be installed at one point. The primary 
compiler for all files is C. At some point someone comes around and says. 
I've got this very nice compiler and it uses the C++ language that is more or 
less compatible with C. Then some code maintainers run of and use all the 
additional features of C++. If this code is then to be a consistent whole, 
this means that all code must be compiled with this C++ compiler. In effect 
replacing C as default language by C++.

It is very hard to revert back to C from C++. The leaders of the group had no 
say in whether it was good to go to C++ (maybe the compilation time is a 
serious issue), but have to accept it at this point because keeping the old C 
compiler is a race long lost.

------------------------------

I do not think that alternative package managers should be limited in what 
they do. What I think is that their additional features should not be used in 
the official tree (overlays is another point) to avoid the situation where 
the council can no longer make the decision to go for the better package 
manager.

There are many changes that can be made without hitting this problem. Multilib 
systems can work in such a way that portage just sees it as one package while 
the multilib package manager knows that it is a package consisting of 3 parts 
(32bit part, shared part, and 64 bit part). It is also possible to have a 
functionally equivalent package database that has a higher speed, or no 
longer needs a cache, than the portage compatible one.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: pauldv@g.o
Homepage: http://www.devrieze.net