Jonathan Coome posted <[EMAIL PROTECTED]>, excerpted below, on Wed, 22 Mar 2006 10:49:29 +0000:
> Taking this idea a bit further, what about proxy maintainers? There seem > to be quite a few packages that are being effectively maintained by > users on bugzilla, but are not in portage because they don't have a > maintainer. A developer could then take these ebuilds, make sure they > don't do anything malicious, or break QA, or whatever, and act as the > bridge between the portage tree and the users actually working on the > ebuild and keeping things up to date and working. [snip the juicy details] I think this sounds very much like the Mandrake contrib packages, back when I was there. It's a decent idea and it seemed to work reasonably well, from a user and active cooker/testing participant. The easiest way to handle "contrib" as far as that "big warning" is to make it a separate tree. That way, folks who want the flexibility get it, but those who prefer not to "risk it", don't have to worry about it. As well, contribs becomes another fertile developer recruitment ground. Unfortunately, for that, portage needs full multi-repository support. Overlays function much that way already, but to do it right, we need multi-repository-update support, and Portage just doesn't have it yet. ... A possible alternative that could be rolled out sooner would be some form of "contrib" eclass. Make it a simple matter to inherit contrib and get the standard contrib warnings and handling. One thing the eclass could handle would be a USE=contrib flag. With it off, the build wouldn't merge. That would take care of user choice. No non-contrib package could dep on a contrib package so if such a dependency came about, either the non-contrib package would have to be dropped (or at least dropped to contrib status even if it was "contributed" by a dev), or the dep raised to full support (non-contrib) status. The dependency rule above would by definition mean that nobody could get contrib accidentally, since the only way to get a contrib package would be merging it or another contrib package that depended on it from the command line. This would also solve the interactivity aka broken emerge session issue, since the portage protest and failure would be right up front, before merging started. Making it a use flag would allow control of specific packages thru package.use, just as now, so a user could decide that he trusted one contributor as the author of a specific package (and his opinion of the dep chain) without forcing it to apply to the entire contrib tree. There remains the question of naming. A contrib-cat/package tree paralleling the main category structure would potentially double the categories right there. Not really practical. cat/package-contrib-ver would be more practical, and allow on-sight identification, but would of course necessitate a package rename if the contrib vs. full-supported status changed. This aspect could be debated if the idea in general gains enough favor to consider a glep or the like. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-dev@gentoo.org mailing list
