[gentoo-perl] Another g-cpan question

[gentoo-perl] Another g-cpan question

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 815 bytes --]

That's right folks, shape the future of the next release of g-cpan!

*cough* *cough*

OK, next question I'm torn on (btw, verdict with 2 whole feedbacks was
that YAML was an acceptable dep). I'm in a position where I can tweak
some simple code based on the more comprehensive dep list and list DEPs,
or I can take some time (and time == slightly larger memory footprint)
and maintain module-version in the DEP list. Thoughts? On the one hand,
g-cpan is a "for entertainment purposes only" tool, ie, the ebuilds it
generates are intended for use on your box only, not for mass
distribution to the masses (for starters, there's no such thing as QA on
what its doing - its the risk you take using something that blindly
installs cpan modules). On the other hand, the power is there to do
it...opinions?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-perl] Another g-cpan question

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

As is often enough the case, soon as I sent this off I realized that
there was really only one 'economical' solution. Sorry for the traffic
folks.

~mcummings

On Mon, 2006-04-17 at 15:54 -0400, Michael Cummings wrote:
> That's right folks, shape the future of the next release of g-cpan!
> 
> *cough* *cough*
> 
> OK, next question I'm torn on (btw, verdict with 2 whole feedbacks was
> that YAML was an acceptable dep). I'm in a position where I can tweak
> some simple code based on the more comprehensive dep list and list DEPs,
> or I can take some time (and time == slightly larger memory footprint)
> and maintain module-version in the DEP list. Thoughts? On the one hand,
> g-cpan is a "for entertainment purposes only" tool, ie, the ebuilds it
> generates are intended for use on your box only, not for mass
> distribution to the masses (for starters, there's no such thing as QA on
> what its doing - its the risk you take using something that blindly
> installs cpan modules). On the other hand, the power is there to do
> it...opinions?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]

Re: [gentoo-perl] Another g-cpan question

[Michael Cummings]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

As is often enough the case, soon as I sent this off I realized that
there was really only one 'economical' solution. Sorry for the traffic
folks.

~mcummings

On Mon, 2006-04-17 at 15:54 -0400, Michael Cummings wrote:
> That's right folks, shape the future of the next release of g-cpan!
> 
> *cough* *cough*
> 
> OK, next question I'm torn on (btw, verdict with 2 whole feedbacks was
> that YAML was an acceptable dep). I'm in a position where I can tweak
> some simple code based on the more comprehensive dep list and list DEPs,
> or I can take some time (and time == slightly larger memory footprint)
> and maintain module-version in the DEP list. Thoughts? On the one hand,
> g-cpan is a "for entertainment purposes only" tool, ie, the ebuilds it
> generates are intended for use on your box only, not for mass
> distribution to the masses (for starters, there's no such thing as QA on
> what its doing - its the risk you take using something that blindly
> installs cpan modules). On the other hand, the power is there to do
> it...opinions?

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]