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