[06/13] cpanminus: new package v3

---
 package/Config.in              |    5 +++++
 package/cpanminus/Config.in    |   28 ++++++++++++++++++++++++++++
 package/cpanminus/cpanminus.mk |   39 +++++++++++++++++++++++++++++++++++++++
 3 files changed, 72 insertions(+)
 create mode 100644 package/cpanminus/Config.in
 create mode 100644 package/cpanminus/cpanminus.mk

Dear Francois Perrad,

On Sat,  8 Sep 2012 14:28:38 +0200, Francois Perrad wrote:

> diff --git a/package/cpanminus/Config.in b/package/cpanminus/Config.in
> new file mode 100644
> index 0000000..d265c2e
> --- /dev/null
> +++ b/package/cpanminus/Config.in
> @@ -0,0 +1,28 @@
> +config BR2_PACKAGE_CPANMINUS
> +	bool "cpanminus"
> +	help
> +	  cpanminus is a script to get, unpack, build and install Perl modules
> +	  from CPAN.
> +
> +	  Why? It's dependency free, requires zero configuration, and stands
> +	  alone. When running, it requires only 10MB of RAM.
> +
> +	  http://github.com/miyagawa/cpanminus
> +
> +if BR2_PACKAGE_CPANMINUS
> +
> +config BR2_PACKAGE_CPANMINUS_MODULES
> +	string "Perl modules from CPAN"
> +	help
> +	  List of space-separated Perl modules to install from CPAN.
> +
> +	  Examples: Try::Tiny Dancer YAML Moo
> +
> +	  Install the listed modules and their dependencies.

Hum, do we really want a package which has configuration options that
allow to select a set of libraries/modules to be downloaded and
installed? It would be more natural to have those Perl modules properly
packaged into Buildroot, no? I suspect that they are all packaged
similarly, so a $(perl-package) infrastructure would work quite well.

This way, we still have the usual package infrastructure for licensing
report and things like this. I honestly don't know if we want packages
whose job is in turn to download/install a bunch of other things. It's
smart, but I'm not sure we want that.

Thomas

On 09/20/12 22:04, Thomas Petazzoni wrote:
> Hum, do we really want a package which has configuration options that
> allow to select a set of libraries/modules to be downloaded and
> installed? It would be more natural to have those Perl modules properly
> packaged into Buildroot, no? I suspect that they are all packaged
> similarly, so a $(perl-package) infrastructure would work quite well.
>
> This way, we still have the usual package infrastructure for licensing
> report and things like this. I honestly don't know if we want packages
> whose job is in turn to download/install a bunch of other things. It's
> smart, but I'm not sure we want that.

  I'm not sure we want to add 100,000 .mk files either...

  Ideally, the cpanminus module should be able to do the right thing for
the -source, -source-check and -legal-info targets.


  Regards,
  Arnout

2012/9/20 Arnout Vandecappelle <arnout@mind.be>:
> On 09/20/12 22:04, Thomas Petazzoni wrote:
>>
>> Hum, do we really want a package which has configuration options that
>> allow to select a set of libraries/modules to be downloaded and
>> installed? It would be more natural to have those Perl modules properly
>> packaged into Buildroot, no? I suspect that they are all packaged
>> similarly, so a $(perl-package) infrastructure would work quite well.
>>
>> This way, we still have the usual package infrastructure for licensing
>> report and things like this. I honestly don't know if we want packages
>> whose job is in turn to download/install a bunch of other things. It's
>> smart, but I'm not sure we want that.
>
>
>  I'm not sure we want to add 100,000 .mk files either...
>
>  Ideally, the cpanminus module should be able to do the right thing for
> the -source, -source-check and -legal-info targets.
>

Perl is useless without a CPAN client.
The Perl packages are fine grained (compared to Python or Ruby ones),
for example the web framework Dancer (without any plugins) requires 22
dependencies (direct or indirect).
Debian has more then thousand Perl packages; I don't want to do the same thing.

Most of CPAN packages haven't a license file; usually the
documentation contains an information, like : "LICENSE - same as Perl
itself".

The reproductibility of a project (with an identified version of each
CPAN module) could be done with a local CPAN mirror.

François

>
>  Regards,
>  Arnout
> --
> Arnout Vandecappelle                               arnout at mind be
> Senior Embedded Software Architect                 +32-16-286540
> Essensium/Mind                                     http://www.mind.be
> G.Geenslaan 9, 3001 Leuven, Belgium                BE 872 984 063 RPR Leuven
> LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
> GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F
>
> _______________________________________________
> buildroot mailing list
> buildroot@busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot

Dear François Perrad,

On Fri, 21 Sep 2012 20:25:14 +0200, François Perrad wrote:

> Perl is useless without a CPAN client.
> The Perl packages are fine grained (compared to Python or Ruby ones),
> for example the web framework Dancer (without any plugins) requires 22
> dependencies (direct or indirect).
> Debian has more then thousand Perl packages; I don't want to do the same thing.
> 
> Most of CPAN packages haven't a license file; usually the
> documentation contains an information, like : "LICENSE - same as Perl
> itself".
> 
> The reproductibility of a project (with an identified version of each
> CPAN module) could be done with a local CPAN mirror.

Ok. I am not a big fan, but I don't care too much about Perl for
embedded systems, and you are the one interested in Perl support, so
let's bring in what you believe is the right solution.

Thomas