sound distribution practices

Alessandro Ghedini al3xbio at gmail.com
Sun Apr 8 14:13:57 UTC 2012


On Sat, Apr 07, 2012 at 07:12:19PM -0700, Allison Randal wrote:
> Patrick and I just chatted on the phone, here's a summary of the working
> scenario we reached:
> 
> - Rakudo will deliver a Rakudo release for each supported ("stable")
> Parrot release, a few days after the Parrot release.
> 
> - Debian will package each supported release of Parrot.

Isn't this what's already happening? I mean, we already package stable Parrot
releases and therefore we can only package Rakudo releases that run on such
Parrot versions.

> Debian packages for Rakudo will either:
> 
> - Rebuild the old Rakudo packages on the new Parrot packages (since the
> old compiled bytecode, etc won't work on a different version of Parrot), or
> 
> - Package the new version of Rakudo at exactly the same time as the new
> version of Parrot. Define the version requirements so tightly (=) that
> the Rakudo packages require exactly one version of Parrot.

A third, and IMO more elegant, solution (that I just thought about), would be
to do (sort of) both and copy what the perl package does to maintain
compatibility with XS modules:

* perl-base provides a virtual package called "perlapi-X.Y.Z" (where X.Y.Z is
  a perl release version such as 5.14.2)

* then, using an automatic script, the XS packages are told, at build time, to
  depend on the perlapi they were built with (Perl packages add a dependency
  on the "${perl:Version}" variable which is replaced by a script, with simply
  "perl" for normal modules and by "perlapi-X.Y.Z" for XS modules at build
  time).

This would allow us to:

* not break Rakudo every time Parrot is updated
* handle the Rakudo rebuilds sort of automatically without the need to make
  modifications to the Rakudo packaging every time
* avoid random breakage during testing migrations and partial stable updates
* scale the whole process if/when other Parrot-based compiler will be uploaded
  to Debian

All this (and your solutions too) would be, of course, more work than a simple
Breaks in the parrot package is, though, my solution, once put in place (and to
do this we can steal and adapt the code from perl) sort of maintains itself.

To do this the Parrot packaging side would only need to

a) add a "Provides: parrotapi-X.Y.Z" to the parrot package (we would probably
   need to move the bytecode libraries shipped by parrot-devel to parrot or to
   their own package too, in order to simplify this) which would need to be
   updated just like libparrotX.Y.Z is already, and
b) parrot should ship a "dh_parrot" script which would handle the automatic
   dependencies substitutions (see the dh_perl script shipped by the
   "debhelper" package).

Now, we kind of already agreed for the move of the bytecode libraries out of the
parrot-devel package (did we?) and I'd like to volunteer to write the dh_parrot
script. Once this is done Parrot and Rakudo packging would become much more
independant one from the other than they are now and make our lives easier
too :)

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.parrot.org/pipermail/parrot-dev/attachments/20120408/31754760/attachment.asc>


More information about the parrot-dev mailing list