| 1 |
On 3/22/06, Duncan <1i5t5.duncan@×××.net> wrote: |
| 2 |
> A possible alternative that could be rolled out sooner would be some form |
| 3 |
> of "contrib" eclass. Make it a simple matter to inherit contrib and get |
| 4 |
> the standard contrib warnings and handling. One thing the eclass could |
| 5 |
> handle would be a USE=contrib flag. With it off, the build wouldn't |
| 6 |
> merge. That would take care of user choice. No non-contrib package could |
| 7 |
> dep on a contrib package so if such a dependency came about, either the |
| 8 |
> non-contrib package would have to be dropped (or at least dropped to |
| 9 |
> contrib status even if it was "contributed" by a dev), or the dep raised |
| 10 |
> to full support (non-contrib) status. |
| 11 |
> |
| 12 |
> The dependency rule above would by definition mean that nobody could get |
| 13 |
> contrib accidentally, since the only way to get a contrib package would be |
| 14 |
> merging it or another contrib package that depended on it from the command |
| 15 |
> line. This would also solve the interactivity aka broken emerge session |
| 16 |
> issue, since the portage protest and failure would be right up front, |
| 17 |
> before merging started. |
| 18 |
> |
| 19 |
> Making it a use flag would allow control of specific packages thru |
| 20 |
> package.use, just as now, so a user could decide that he trusted one |
| 21 |
> contributor as the author of a specific package (and his opinion of the |
| 22 |
> dep chain) without forcing it to apply to the entire contrib tree. |
| 23 |
> |
| 24 |
> There remains the question of naming. A contrib-cat/package tree |
| 25 |
> paralleling the main category structure would potentially double the |
| 26 |
> categories right there. Not really practical. cat/package-contrib-ver |
| 27 |
> would be more practical, and allow on-sight identification, but would of |
| 28 |
> course necessitate a package rename if the contrib vs. full-supported |
| 29 |
> status changed. This aspect could be debated if the idea in general gains |
| 30 |
> enough favor to consider a glep or the like. |
| 31 |
|
| 32 |
Maybe taking a slightly different approach at this same idea is what |
| 33 |
needs done. Create a new mask level for contrib where anything deemed |
| 34 |
"stable" yet unmaintained could go so that users will have access to |
| 35 |
it without needing to search bugzilla or some third-party site. I |
| 36 |
would also propose an unstable mask as well where testing ebuilds can |
| 37 |
go, things that are in bugzilla but have not yet been vetted. The |
| 38 |
process for getting unstable ebuilds from bugzilla to portage could |
| 39 |
even be automated to the extent that when an ebuild is put into |
| 40 |
bugzilla it gets auto committed to the tree but masked unstable. This |
| 41 |
way all the "latest greatest" ebuilds are always available in the tree |
| 42 |
but it requires the user to consciously unmask them for use. You could |
| 43 |
even add a big red warning for unstable ebuilds to let people know |
| 44 |
that they should examine the ebuild before emerging... just so if they |
| 45 |
DO get rooted due to a bad ebuild you can say they where warned. |
| 46 |
|
| 47 |
You could further extend the process of emerging unstable ebuilds so |
| 48 |
that a successful emerge would create a vote "for" the ebuild in |
| 49 |
bugzilla (attached to the original ebuild bug) and an unsuccessful |
| 50 |
emerge would allow the user to add a comment/vote against the ebuild |
| 51 |
in bugzilla. |
| 52 |
|
| 53 |
Perhaps it is a radical approach but that's just my $0.02 on how to |
| 54 |
open the dev community. |
| 55 |
|
| 56 |
-Mike |
| 57 |
|
| 58 |
-- |
| 59 |
________________________________ |
| 60 |
Michael E. Crute |
| 61 |
http://mike.crute.org |
| 62 |
|
| 63 |
It is a mistake to think you can solve any major problems just with potatoes. |
| 64 |
--Douglas Adams |
| 65 |
|
| 66 |
-- |
| 67 |
gentoo-dev@g.o mailing list |
Archives