| 1 |
As is often enough the case, soon as I sent this off I realized that |
| 2 |
there was really only one 'economical' solution. Sorry for the traffic |
| 3 |
folks. |
| 4 |
|
| 5 |
~mcummings |
| 6 |
|
| 7 |
On Mon, 2006-04-17 at 15:54 -0400, Michael Cummings wrote: |
| 8 |
> That's right folks, shape the future of the next release of g-cpan! |
| 9 |
> |
| 10 |
> *cough* *cough* |
| 11 |
> |
| 12 |
> OK, next question I'm torn on (btw, verdict with 2 whole feedbacks was |
| 13 |
> that YAML was an acceptable dep). I'm in a position where I can tweak |
| 14 |
> some simple code based on the more comprehensive dep list and list DEPs, |
| 15 |
> or I can take some time (and time == slightly larger memory footprint) |
| 16 |
> and maintain module-version in the DEP list. Thoughts? On the one hand, |
| 17 |
> g-cpan is a "for entertainment purposes only" tool, ie, the ebuilds it |
| 18 |
> generates are intended for use on your box only, not for mass |
| 19 |
> distribution to the masses (for starters, there's no such thing as QA on |
| 20 |
> what its doing - its the risk you take using something that blindly |
| 21 |
> installs cpan modules). On the other hand, the power is there to do |
| 22 |
> it...opinions? |
Archives