On Saturday 20 May 2006 11:51, Thomas Cort wrote: > On Sat, 20 May 2006 14:54:18 +0200 > > Paul de Vrieze <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpyE9SbwJp4b.pgp
Description: PGP signature
