Just a note...<br><br>I would avoid conflating Perl 6 modules to Rakudo or Parrot. Perl 6 is only a language specification (kinda like C++ 98), not a language implementation. It has many implementations (none of which are called Perl 6), and Rakudo is just one. If you are going to package modules for the Perl 6 specification, you should do so without regard to any particular implementation.<br>
<br>Cheers, Ingy<br><br><div class="gmail_quote">On Wed, Oct 12, 2011 at 1:33 PM, Alessandro Ghedini <span dir="ltr"><<a href="mailto:al3xbio@gmail.com" target="_blank">al3xbio@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry for the delay. Your email somehow got buried in my inbox :/<br>
<div><br>
On Tue, Oct 04, 2011 at 10:47:45AM +0200, Dominique Dumont wrote:<br>
> On Saturday 01 October 2011 13:58:35 Alessandro Ghedini wrote:<br>
> > 1) We need a standard way to build those packages (there's no such thing<br>
> > as ExtUtils::MakeMaker for Perl6). The panda module manager uses a<br>
> > script called ufo [0] which basically generates a Makefile out of every<br>
> > file it finds under lib/, bin/, etc. There are a couple of issues with<br>
> > it though:<br>
> ><br>
> > a) by default it compiles *.pm files to PIR to improve performance. This<br>
> > may make those files dependant on a specific parrot version.<br>
> > b) IIRC it installs those *.pir files to a versioned directory,<br>
> > something like "/usr/local/lib/parrot/X.Y.Z/..." or so.<br>
> > may not work anymore.<br>
> ><br>
> > Both of them may cause all the Perl6 packages to need a rebuild after<br>
> > each new parrot upload.<br>
><br>
> Which happens every 3 months. Given that there are very few Perl6 modules<br>
> worth packaging, this may be a valid solution for the short or middle term.<br>
<br>
</div>It may work in the short term, but doesn't scale very much. I'd rather pick<br>
up a working (well, at least in theory) model from the beginning, in order<br>
to avoid us some painful work of "re-do all the packages" (even if they are<br>
few) in the future.<br>
<div><br>
> > The obvious solution is to make our own script that does not compile<br>
> > to PIR and installs the modules to a directory we want (something called<br>
> > e.g. dh_perl6). I didn't try yet to write anything useful though. Also<br>
> > note that this may decrease the performance of modules loading<br>
> > significantly (I only tried with the old rakudo in Debian, rakudo<br>
> > 2011.09 should improve overall performance).<br>
><br>
> Another solution is to have package triggers that re-compile to PIR when<br>
> parrot is installed<br>
<br>
</div>Same as above.<br>
<div><br>
> > 2) According to "Perl 6 Policy" [1], the Perl6 modules should be installed<br>
> > under "/usr/share/perl6" but rakudo does not "support" it. We should<br>
> > patch rakudo to support that path (as the Ruby maintainers are doing for<br>
> > ruby).<br>
><br>
> May be we could ask upstream.<br>
<br>
</div>It looks like a trivial patch, but yes, for the longterm this is preferred.<br>
<div><br>
> > 3) Most of the Perl6 modules [2] do not state copyright and licensing<br>
> > information, some of them do not even try to properly version the code,<br>
> > and other are flagged as "experimental". We should then file bugs<br>
> > upstream for every module we would want to package. This is IMHO the<br>
> > most serious issue.<br>
><br>
> We can start this way. Once we (as Debian) make some noise about this issue,<br>
> I'm pretty sure that upstream authors will clean up this legal points. At<br>
> least for modules worth packaging.<br>
<br>
</div>Agreed.<br>
<div><br>
> > 4) IIRC some of the modules may not work with the new rakudo 2011.09 due to<br>
> > all the changes it introduces. The risk is that we package some modules<br>
> > for v2011.07 and then have to remove them, because they don't work with<br>
> > v2011.09.<br>
><br>
> This may happen. We can mitigate the risk by picking well maintained modules<br>
> (may be LWP::Simple). We can aslo talk with upstream before spending time on a<br>
> "toy" module.<br>
><br>
> At this point, we don't want to package all Perl6 modules. I think that just<br>
> choosing carefully and packaging one or 2 modules will be enough to dig up<br>
> most issues.<br>
<br>
</div>Again, agreed.<br>
<div><br>
> > Also, there's no such thing as CPAN for Perl6 so that we would have to<br>
> > generate the tarballs directly from the git repositories (this wouldn't<br>
> > have been an issue if modules' maintainers properly versioned their modules<br>
> > with e.g. git tags, given that all of them are on GitHub).<br>
><br>
> Hmm, most of Perl5 strength come from CPAN. Perl6 without a CP6AN (or CPAN6,<br>
> whatever) may never take off. I wonder if (how) current CPAN could host Perl6<br>
> modules ?<br>
<br>
</div>Currently the only thing that looks like a centralised repository is this<br>
<a href="https://github.com/perl6/ecosystem" target="_blank">https://github.com/perl6/ecosystem</a><br>
<br>
I suspect that the current CPAN infrastructure doesn't work with Perl6<br>
modules for the same reason that dh-make-perl doesn't: the META.info thing.<br>
I don't know of any plan for making it work.<br>
<br>
Cheers<br>
<div><br>
--<br>
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'<br>
<br>
<br>
</div><div>--<br>
To UNSUBSCRIBE, email to <a href="mailto:debian-perl-REQUEST@lists.debian.org" target="_blank">debian-perl-REQUEST@lists.debian.org</a><br>
with a subject of "unsubscribe". Trouble? Contact <a href="mailto:listmaster@lists.debian.org" target="_blank">listmaster@lists.debian.org</a><br>
</div>Archive: <a href="http://lists.debian.org/20111012173316.GA25606@PC-Ale.fastwebnet.it" target="_blank">http://lists.debian.org/20111012173316.GA25606@PC-Ale.fastwebnet.it</a><br>
<br>
</blockquote></div><br>