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? |