On 3/22/06, Duncan <[EMAIL PROTECTED]> wrote: > 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.
Maybe taking a slightly different approach at this same idea is what needs done. Create a new mask level for contrib where anything deemed "stable" yet unmaintained could go so that users will have access to it without needing to search bugzilla or some third-party site. I would also propose an unstable mask as well where testing ebuilds can go, things that are in bugzilla but have not yet been vetted. The process for getting unstable ebuilds from bugzilla to portage could even be automated to the extent that when an ebuild is put into bugzilla it gets auto committed to the tree but masked unstable. This way all the "latest greatest" ebuilds are always available in the tree but it requires the user to consciously unmask them for use. You could even add a big red warning for unstable ebuilds to let people know that they should examine the ebuild before emerging... just so if they DO get rooted due to a bad ebuild you can say they where warned. You could further extend the process of emerging unstable ebuilds so that a successful emerge would create a vote "for" the ebuild in bugzilla (attached to the original ebuild bug) and an unsuccessful emerge would allow the user to add a comment/vote against the ebuild in bugzilla. Perhaps it is a radical approach but that's just my $0.02 on how to open the dev community. -Mike -- ________________________________ Michael E. Crute http://mike.crute.org It is a mistake to think you can solve any major problems just with potatoes. --Douglas Adams -- [email protected] mailing list
