| 1 |
On Thu, Jul 20, 2006 at 09:39:14PM +0200, Luca Longinotti wrote: |
| 2 |
> John Jawed wrote: |
| 3 |
> > Below is a link to an "enhanced input" eclass as well as a screenshot. |
| 4 |
> > This eclass was made to simplify interacting with the user at |
| 5 |
> > pkg_config(). |
| 6 |
> |
| 7 |
> This is a good idea imo, it could really simplify and help with |
| 8 |
> pkg_config stuff, think of dev-db/mysql or others who need to ask |
| 9 |
> questions, passwords etc., this would help doing that in a simple, |
| 10 |
> standardized way. Maintainance is no problem, I'm willing to put this |
| 11 |
> eclass in the tree and maintain it myself for now, and when John will |
| 12 |
> become a full Gentoo dev (this is already scheduled, he'll help out on |
| 13 |
> PostgreSQL related stuff in the near future), he can take it over |
| 14 |
> directy... Any objections to this wandering into the tree? Suggestions, |
| 15 |
> ideas? Thanks! |
| 16 |
|
| 17 |
Examples of converted ebuilds would be wise prior to plopping it into |
| 18 |
the tree imo- fex, displayConfirmPrompt looks like it should be |
| 19 |
reliant on exit codes rather then mangling a global var to indicate |
| 20 |
the outcome; that would shift it more towards "get confirmation" |
| 21 |
rather then display. |
| 22 |
|
| 23 |
Hence Why I think examples would be useful- eclass api can only be |
| 24 |
extended once it's in the tree. I'd go and build up consumers of the |
| 25 |
eclass to |
| 26 |
A) show off |
| 27 |
B) find the weak spots in your eclass api _now_ rather then having to |
| 28 |
do an einput{1..N}.eclass |
| 29 |
|
| 30 |
Aside from that, not sure about the RC_NOCOLOR fiddling in initInput- |
| 31 |
haven't checked, but that should be handled by ebuild.sh already via |
| 32 |
the profile sourcing. |
| 33 |
|
| 34 |
~harring |
Archives