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

[Paul de Vrieze]

On Saturday 20 May 2006 11:51, Thomas Cort wrote:
> On Sat, 20 May 2006 14:54:18 +0200
>
> Paul de Vrieze <pauldv@g.o> wrote:
> > *Primary Package Manager*
> >    There  is one primary  package manager.
>
> Gentoo has always been about choice, could you explain what is the
> rationale behind having only one primary package manager?

Ok, I'll go along the various situations with two primary package managers 
that can exist (it has to do with network effects):

- There are two primary package managers, A and B. Package manager B accepts 
ebuilds that package manager A does not accept. At this point package manager 
B is the most useful. As there is no problem with using package manager B, 
all authors who need package manager B features use it. They forget about 
package manager A. As a result, it will not be long before a significant part 
of the tree does no longer work with package manager A. It is only a matter 
of time before the (often highly complex, and in need of such features) core 
packages that everyone needs is in this set. Effectively obsoleting package 
manager A.

- There are two primary package managers, C and D. Each one supports features 
the other one doesn't. While this situation seems different, it actually 
isn't that different. In the beginning they each have 50% of the packages 
that are not usable by both. At some point this 50% will change. At that time 
ebuild authors have to choose when they need a new feature. In most cases 
they will choose for that package manager (D) that is used by most people. 
This increases the incentives for users to use package manager D. This again 
leads more ebuild authors into using package manager D, etc. Again leading to 
one package manager to be obsoleted.

The situations described above are what is called a network effect. They show 
why everyone uses internet instead of some people using compuserve, some 
people america online, some people internet, and yet some other people still 
using bbs systems. It also explains why windows is by nature a monopoly and 
why linux has such problems being an alternative operating system (see the 
interaction between features, compatibility and amount of users).

> > All ebuilds in the tree must function with the primary package
> > manager.
>
> I definitely see this is as a requirement. One thing I am wondering is, who
> is responsible for testing the over 24,000 ebuilds in the tree to make sure
> that they work with the new package manager? Is it the package manager
> team, arch teams, package/herd maintainers, arch/herd testers, or others?

The other package manager team is responsible for initial testing. At a point 
where a package manager is accepted as candidate replacement or secondary 
package manager, it is acceptable that bugs are filed against packages that 
do not work with the other package manager. If they are caused by the 
standard (written standard, not things that are accepted by the primary by 
accident) not being accepted by the secondary or candidate replacement 
package manager this is a bug on that package manager, otherwise on the 
violating package. For a secondary package manager this only, when its usage 
makes sense on the package in the first place.

> > The primary package manager is maintained on official gentoo
> > infrastructure, under control of gentoo developers.
>
> I don't really see this as a requirement. Many Linux distributions use
> package managers that they don't have direct control over. Ubuntu uses apt,
> Mandrake uses rpm, etc.

Those are binary distributions. Even they have extensions in their own package 
managers. Binary distribution is easier than from source. One of the 
strengths of Gentoo is formed by the package manager. If the package manager 
is out of control of gentoo, this means that Gentoo no longer has control 
over its future or its features.

Paul

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