[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How about packaging Perl6 modules ?

On Saturday 01 October 2011 13:58:35 Alessandro Ghedini wrote:
> 1) We need a standard way to build those packages (there's no such thing
>    as ExtUtils::MakeMaker for Perl6). The panda module manager uses a
>    script called ufo [0] which basically generates a Makefile out of every
>    file it finds under lib/, bin/, etc. There are a couple of issues with
> it though:
>    a) by default it compiles *.pm files to PIR to improve performance. This
>       may make those files dependant on a specific parrot version.
>    b) IIRC it installs those *.pir files to a versioned directory,
> something like "/usr/local/lib/parrot/X.Y.Z/..." or so.
>       may not work anymore.
>    Both of them may cause all the Perl6 packages to need a rebuild after
>    each new parrot upload.

Which happens every 3 months. Given that there are very few Perl6 modules 
worth packaging, this may be a valid solution for the short or middle term.

>    The obvious solution is to make our own script that does not compile
>    to PIR and installs the modules to a directory we want (something called
>    e.g. dh_perl6). I didn't try yet to write anything useful though. Also
>    note that this may decrease the performance of modules loading
>    significantly (I only tried with the old rakudo in Debian, rakudo
>    2011.09 should improve overall performance).

Another solution is to have package triggers that re-compile to PIR when 
parrot is installed

> 2) According to "Perl 6 Policy" [1], the Perl6 modules should be installed
>    under "/usr/share/perl6" but rakudo does not "support" it. We should
>    patch rakudo to support that path (as the Ruby maintainers are doing for
>    ruby).

May be we could ask upstream.

> 3) Most of the Perl6 modules [2] do not state copyright and licensing
>    information, some of them do not even try to properly version the code,
>    and other are flagged as "experimental". We should then file bugs
>    upstream for every module we would want to package. This is IMHO the
>    most serious issue.

We can start this way. Once we (as Debian) make some noise about this issue, 
I'm pretty sure that upstream authors will clean up this legal points. At 
least for modules worth packaging.

> 4) IIRC some of the modules may not work with the new rakudo 2011.09 due to
>    all the changes it introduces. The risk is that we package some modules
>    for v2011.07 and then have to remove them, because they don't work with
>    v2011.09.

This may happen. We can mitigate the risk by picking well maintained modules
(may be LWP::Simple). We can aslo talk with upstream before spending time on a 
"toy" module.

At this point, we don't want to package all Perl6 modules. I think that just 
choosing carefully and packaging one or 2 modules will be enough to dig up 
most issues.

> Regarding package names, [1] states that they should be named lib*-perl6. I
> think this may be changed if we wanted, but I'd rather keep it, to maintain
> some sort of "integration" with Perl5 modules (more over if they are going
> to be maintained by the Perl Group).

My bad. I remembered the discussion, I did not remember the conclusion. This 
naming scheme is fine with me.
> Regarding dh-make-perl, I didn't try it, but I'm quite sure it won't work
> with Perl6 modules due to the new META.info thing (that should replace
> META.{yaml,json}). I am not a dh-make-perl expert but this shouldn't be
> difficult to fix (META.info is just a json document), and add, I don't
> know, a --perl6 flag? But we should find some sort of workflow for Perl6
> packages first.


> Also, there's no such thing as CPAN for Perl6 so that we would have to
> generate the tarballs directly from the git repositories (this wouldn't
> have been an issue if modules' maintainers properly versioned their modules
> with e.g. git tags, given that all of them are on GitHub).

Hmm, most of Perl5 strength come from CPAN. Perl6 without a CP6AN (or CPAN6, 
whatever) may never take off. I wonder if (how) current CPAN could host Perl6 
modules ?

> There shouldn't be any issue with lintian. It used to warn about the
> unknown perl6 interpreter (#636354) but this is now fixed and I can't
> think of any other issue that may arise.
> That's all, I think. Most of the above issues are easily fixed, some other
> (e.g. the third) may require some more time, but are "doable" with some
> patience.

Cool :-)

http://config-model.wiki.sourceforge.net/ -o- http://search.cpan.org/~ddumont/
http://www.ohloh.net/accounts/ddumont     -o- http://ddumont.wordpress.com/

Reply to: