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: [EMAIL PROTECTED] Homepage: http://www.devrieze.net
pgpJzZ0bXo3Kp.pgp
Description: PGP signature
