Re: sound distribution practices

[Alessandro Ghedini]

On Sun, Apr 08, 2012 at 09:46:18AM -0700, Allison Randal wrote:
 On 04/08/2012 09:29 AM, Alessandro Ghedini wrote:
  
  If we go down the split to different libraries path, those libraries 
  should
  depend on parrotapi-* too so that not only Parrot isn't updated but the
  libraries aren't too. Or alternatively parrot should strictly depend on 
  them.
 
 Makes sense for the libraries that move to separate source packages.
 But, would it be necessary for libraries in binary packages built from
 the parrot source package?

The parrotapi-* thing would avoid an update of the parrot package, but there's
nothing that would avoid an update of, say, libdata-dumper-parrot, and it would
leave the system with an older version of parrot and a newer version of the
bytecode library, which, as Patrick pointed out, are not compatible. If the
library depends on parrotapi-* too, it is not updated until every other
parrotapi-* reverse dependencies are ready to be updated.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Re: sound distribution practices

[Andrew Whitworth]

What if we did something like bundling? Practically speaking, for at
least the foreseeable future, Rakudo requires Parrot and the primary
user of Parrot is Rakudo. Offering two separate packages for such a
closely-knit pair almost seems like a waste (it won't always be, but
let's be honest about the current situation). As Jonathan and Patrick
mention, both projects are still in a development mode and not
really a deploy mode, in many ways, and changes in one are often
going to lead quickly to changes in the other.

I would love to see NQP and Rakudo snapshotted into Parrot
distributions or, as might be more favorable from a Rakudo
perspective, to have Parrot snapshotted into Rakudo release packages.
I obviously am not making the releases myself, so I don't know if this
is any easier for people in that role.

--Andrew Whitworth



On Sat, Apr 7, 2012 at 7:27 PM, Patrick R. Michaud pmich...@pobox.com wrote:
 On Sat, Apr 07, 2012 at 03:24:37PM -0700, Allison Randal wrote:
 These are things that Rakudo shouldn't care about. A bug-fix or
 performance enhancement in Parrot is good, but doesn't actually affect
 Rakudo's ability to build or run.

 Sometimes it does.  See the flurry of difficulties we had last April
 and May when Rakudo testing discovered that Parrot performance had
 declined by 100% over the previous several months (and Parrot
 developers were completely unaware of it).

 Did the actual APIs change?  Different arguments required, or
 substantially different behavior so that there was absolutely no way
 Rakudo could run on both the old and new versions of Parrot?

 I can think of several instances where the APIs changed, such that
 Rakudo could no longer run on an older Parrot or would require
 substantial detection of which version of Parrot is being used
 and change code generation or behavior accordingly.

 If so, then Parrot could be doing a better job of supporting
 language development here, by preserving old APIs.

  One is due to getting a PAST improvement:
 [...]
 This is eager adoption of new features again. But, in this case I agree
 the fix is that PAST should move to NQP and out of the Parrot packages
 entirely. For one thing, having NQP depend on a library in Parrot that
 depends on NQP is nightmarish for packaging.

 FWIW, I don't think this circular dependency exists (Jonathan doesn't
 think so either).  AFAIK, there's nothing in Parrot that has any sort
 of dependency on NQP.  (Note that there's a distinction between
 nqp and nqp-rx; Parrot includes some nqp-rx stuff, but doesn't
 make use of nqp.)

 Indeed, not enough detail there for much analysis. But, in general there
 is a difference between what you choose as your development process, and
 what you choose as your release process. It is very sensible to always
 test Rakudo against the latest versions of Parrot. But, that doesn't
 mean you can stop testing against older version of Parrot. The most
 important older versions to test against are the ones shipped in various
 distributions.
 [...]
 It would also be helpful if Rakudo and NQP adopted more strategies to
 keep the minimum required version as low as possible. Like soft
 launching new features so they're simply not available when they depend
 on a newer Parrot feature.

 I will go back and test, but I'm willing to hazard a guess that
 there are very few Rakudo releases that would be able to go very far back
 in Parrot's release history and still be functional, even with a sort of
 soft launching described here.

 For a recent and directly on topic example, take a look at
 https://github.com/perl6/nqp/commit/242f6e5997f6c454246fcf97b8a2a5d038d95931 ,
 provided to NQP by a Parrot developer on March 5.  This commit means
 that subsequent versions of NQP and Rakudo are absolutely unable to
 work with any version of Parrot prior to 4.2.0, because it's
 an API change.  I also don't see any soft launch for this commit
 that would make it easy for Rakudo/NQP to preserve access to
 older versions of Parrot.

 (Better would probably have been for Parrot to introduce a new opcode
 with the correct order of arguments rather than changing the API of
 an existing opcode, but that's not what happened here, and the API
 change was not introduced at the request of Rakudo/NQP.  As far as
 we can tell it came entirely from the Parrot development team.)

 I guess that raises the question for me of whether Rakudo is ready to be
 packaged. I don't have any trouble with Parrot packaging, but I do get a
 regular series of unusual requests from the Rakudo packagers. If the
 Rakudo project is totally focused on the use-case of downloading the
 source code or checking out from git and compiling from source, maybe
 it's just not ready for packaging.
 [...]
 I'm sure all the Rakudo packagers will agree with me that they'd really
 hate to remove it from Debian. But, if packaging isn't something Rakudo
 wants to support, then we shouldn't force the project into a different
 mindset. To give you an 

Re: sound distribution practices

[Alessandro Ghedini]

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'


signature.asc
Description: Digital signature

Re: sound distribution practices

[Alessandro Ghedini]

On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote:
 What if we did something like bundling?

Isn't this what Rakudo Star does? AFAICT the Star distribution is nothing more
than a bundle of rakudo + nqp + parrot + some Perl 6 modules, which may be nice
from a end user POV, but it's plain wrong from a distribution one. We (Debian)
have different source packages for Parrot, Rakudo and NQP (which are managed by
two diffent teams) so that we can handle issues and changes separately without
the need to rebuild all of them every time one needs to be changed. Bundling
them together would just make the Parrot and Rakudo packages more dependant on
each other... which is exactly what we are trying to avoid. Also see the third
paragraph of [0]. Btw, this also applies to NQP bundling full source of
libtommath and dyncall.

(/me being one of the Debian Rakudo maintainers)

Cheers

[0] http://wiki.debian.org/UpstreamGuide#Pristine_Upstream_Source

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Re: sound distribution practices

[Alessandro Ghedini]

On Sun, Apr 08, 2012 at 08:42:21PM +0200, Moritz Lenz wrote:
 On 04/08/2012 06:53 PM, Alessandro Ghedini wrote:
  On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
  On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini wrote:
   On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote: 
   Btw, this also applies to NQP bundling full source of
   libtommath and dyncall.
  
  We'll work on removing the libtomath and dyncall sources from NQP 
  tarballs, or make it very easy for NQP to ignore those sources.
  
  Thanks. As far as I'm concerned something simple as a Configure.pl option 
  (say,
  --use-system-libraries) or an environment variable would do
 
 Unfortunately from our point of view it's not that simple, because we
 have some patches to those libs; we'll try to push them upstream, but
 it'll take some time to do that and to get them all accepted.

What kind of patches? We may try to get those included in the Debian packages
for the two libraries if they are not too excessive.

Also, I was wondering why did you choose libtommath and dynacall, instead of,
say, GMP and FFI? (I'm just curious).

Anyway, I did not hope of that change being made from one day to the other, and
I'm glad you are aware of the problem and you recognize it as something to fix.

Cheers

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;inidehG ordnasselA;eg;say~~reverse'


signature.asc
Description: Digital signature

Re: sound distribution practices

[Moritz Lenz]

On 04/09/2012 09:10 PM, Alessandro Ghedini wrote:
 On Sun, Apr 08, 2012 at 08:42:21PM +0200, Moritz Lenz wrote:
 On 04/08/2012 06:53 PM, Alessandro Ghedini wrote:
  On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
  On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini wrote:
   On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote: 
   Btw, this also applies to NQP bundling full source of
   libtommath and dyncall.
  
  We'll work on removing the libtomath and dyncall sources from NQP 
  tarballs, or make it very easy for NQP to ignore those sources.
  
  Thanks. As far as I'm concerned something simple as a Configure.pl option 
  (say,
  --use-system-libraries) or an environment variable would do
 
 Unfortunately from our point of view it's not that simple, because we
 have some patches to those libs; we'll try to push them upstream, but
 it'll take some time to do that and to get them all accepted.
 
 What kind of patches?

For dyncall mostly build fixes for cygwin and windows.
For libtommath a few additional features: conversion from and to double
precision floats, and extraction of machine-size integers.

One of the libtommath developers has expressed mild interest in the
float conversion routines, I just have to polish them to the standard of
the upstream maintainers.

 We may try to get those included in the Debian packages
 for the two libraries if they are not too excessive.
 
 Also, I was wondering why did you choose libtommath and dynacall, instead of,
 say, GMP and FFI? (I'm just curious).

Because both GMP and FFI are both quite hard to build on Windows.
Yes, I know, Debian maintainers usually don't worry about that :-), but
we need to consider a big part of our potential user base.

Re: sound distribution practices

[Patrick R. Michaud]

On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini wrote:
 On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote:
  What if we did something like bundling?
 
 Isn't this what Rakudo Star does? AFAICT the Star distribution is nothing 
 more
 than a bundle of rakudo + nqp + parrot + some Perl 6 modules, which may be 
 nice
 from a end user POV, but it's plain wrong from a distribution one. We (Debian)
 have different source packages for Parrot, Rakudo and NQP (which are managed 
 by
 two diffent teams) so that we can handle issues and changes separately without
 the need to rebuild all of them every time one needs to be changed.  

Unfortunately, aiui Parrot's current implementation requires that 
all of its downstream users (including Rakudo and NQP) must be 
rebuilt every time Parrot is changed.  Bytecode files created for one 
version of Parrot cannot be directly used with a later version of 
Parrot -- they must be regenerated.

Rakudo releases often require newer versions of Parrot, but that tends to
be because of changes to Parrot APIs or features also.  For example, 
Parrot 4.2.0 introduced an substantial API change that completely breaks 
downstream compatibility with previous versions of Parrot for Rakudo/NQP.
Historically, this sort of API breakage within Parrot has occurred at 
least once or twice per year -- at least often enough that it has been
nearly impossible for any Rakudo release to be buildable on two separate
Parrot supported releases.  (I suppose Rakudo could conceivably try to 
maintain separate development branches for each release of Parrot... 
but we're quite reluctant to do that.)

 Bundling them together would just make the Parrot and Rakudo packages 
 more dependant on each other... which is exactly what we are trying 
 to avoid. 

I totally agree the tight coupling between the packages is undesirable.
Any fix for this will likely have to come from Parrot, though -- afaict
Rakudo/NQP really can't do much about it on their own.

 Btw, this also applies to NQP bundling full source of
 libtommath and dyncall.

We'll work on removing the libtomath and dyncall sources from NQP 
tarballs, or make it very easy for NQP to ignore those sources.

Pm

Re: sound distribution practices

[Patrick R. Michaud]

On Sun, Apr 08, 2012 at 06:53:49PM +0200, Alessandro Ghedini wrote:
 On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
  Unfortunately, aiui Parrot's current implementation requires that 
  all of its downstream users (including Rakudo and NQP) must be 
  rebuilt every time Parrot is changed.  Bytecode files created for one 
  version of Parrot cannot be directly used with a later version of 
  Parrot -- they must be regenerated.
 
 This is true for newer upstream Parrot releases, but it happens that Debian
 packages require new uploads only to do Debian-specific changes (e.g. changes 
 to
 the packaging, small patches to the upstream code, ...) and the need to 
 rebuild
 Rakudo, NQP *and* Parrot just because I need to do a small change to the 
 packaging
 of, say, NQP is just putting more unnecessary burden on the Debian
 infrastructure (build daemons, ftp master, mirrors, ...).

I'm not quite able to follow here -- could you explain further or give
an example?  I mean, I understand how changes to NQP can affect
Rakudo, but I don't understand why/how it affects Parrot.

Pm

Re: sound distribution practices

[Patrick R. Michaud]

On Sun, Apr 08, 2012 at 07:32:55PM +0200, Alessandro Ghedini wrote:
 On Sun, Apr 08, 2012 at 12:15:44PM -0500, Patrick R. Michaud wrote:
  I'm not quite able to follow here -- could you explain further or give
  an example?  I mean, I understand how changes to NQP can affect
  Rakudo, but I don't understand why/how it affects Parrot.
 
 Well, I was talking about Rakudo Star. If I have a rakudo-star source package,
 which includes the sources and builds packages for NQP, Rakudo and Parrot, 
 then
 if I need to do a change to the NQP packaging (which doesn't involve upstream
 sources updates) I'd also have to reupload the whole source package, which in
 turn means that not only NQP, but also Rakudo and Parrot would be rebuilt too.

Ah, I didn't realize you were referring to Rakudo Star, that's the likely
point of confusion.  

I fully agree that Rakudo Star is not at all Debian-packager-friendly as 
it exists now.  We still have some work to do on figuring out how to 
bundle/package Perl 6 modules and handle dependencies there -- Star has just
been our first forays into a full Perl 6 distribution.  It's always been
the plan and expectation that other Rakudo Perl 6 distribution and bundling 
systems will arise.

Pm

Re: sound distribution practices

[Moritz Lenz]

On 04/08/2012 06:53 PM, Alessandro Ghedini wrote:
 On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
 On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini wrote:
  On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote: 
  Btw, this also applies to NQP bundling full source of
  libtommath and dyncall.
 
 We'll work on removing the libtomath and dyncall sources from NQP 
 tarballs, or make it very easy for NQP to ignore those sources.
 
 Thanks. As far as I'm concerned something simple as a Configure.pl option 
 (say,
 --use-system-libraries) or an environment variable would do

Unfortunately from our point of view it's not that simple, because we
have some patches to those libs; we'll try to push them upstream, but
it'll take some time to do that and to get them all accepted.

Cheers,
Moritz

Re: sound distribution practices

[Patrick R. Michaud]

On Sun, Apr 08, 2012 at 08:42:21PM +0200, Moritz Lenz wrote:
 On 04/08/2012 06:53 PM, Alessandro Ghedini wrote:
  On Sun, Apr 08, 2012 at 11:09:30AM -0500, Patrick R. Michaud wrote:
  On Sun, Apr 08, 2012 at 03:23:26PM +0200, Alessandro Ghedini wrote:
   On Sat, Apr 07, 2012 at 09:08:21PM -0400, Andrew Whitworth wrote: 
   Btw, this also applies to NQP bundling full source of
   libtommath and dyncall.
  
  We'll work on removing the libtomath and dyncall sources from NQP 
  tarballs, or make it very easy for NQP to ignore those sources.
  
  Thanks. As far as I'm concerned something simple as a Configure.pl option 
  (say,
  --use-system-libraries) or an environment variable would do
 
 Unfortunately from our point of view it's not that simple, because we
 have some patches to those libs; we'll try to push them upstream, but
 it'll take some time to do that and to get them all accepted.

Jonathan Worthington also tells me (and thus I'm passing along to
this list for information) that the libs bundled with nqp are 
statically linked in the executables, so at present there's no real 
version or installation conflict with any system versions 
of the same libraries.

We recognize this isn't ideal and will likely work to change it,
but apparently it's not as simple or trivial as just saying use 
the system-installed versions of the libraries.

Pm

Re: sound distribution practices

[Jonathan Worthington]

On 4/7/2012 19:11, Allison Randal wrote:

Okay, instead of just complaining about this, I want to do something
about it. The Rakudo packages are so fragile on Debian, that they need
special constraints to make sure the Parrot packages are held back until
the Rakudo packages are updated.

So, why is Rakudo so dependent on one specific month release of Parrot?
Parrot isn't moving so fast that the APIs are all changing every month.
Is NQP or Rakudo not respecting API boundaries? Are there some libraries
currently shipping in Parrot that should be in NQP, Rakudo, or broken
out into their own distributions instead?
Easiest way to analyze it is just git log on 
build/tools/PARROT_REVISION. Here I've done a very rough categorization 
of the last 20 entries (which takes us back to October).


Some of them are to take advantage of Parrot feature additions:

bump PARROT_REVISION to get separate unlink and rmdir primtives

use parrot's new Hash.update method to speed up method cache generation

bump parrot revision to one that has the is_inf_or_nan opcode

use parrot op to switch to the profiling runcore

So not bumping would mean Rakudo forgoing making user-facing improvements.

Some are to get Parrot fixes:

bump parrot revision to get MacOS build fixes

Bump to a Parrot version with a fix for ByteBuffer segfaults, which 
caused programs using Buf to sometimes segfault.


Again, there are Rakudo user benefits to following this.

Some are due to chasing API changes in Parrot:

Update to new version of getprop op

Bump parrot revision to kill_props_vtables marge commit.

The getprop op changed at a PIR level. No guts poking here, just a (for 
the better) change. I should add that when I say chasing in reality 
Parrot folks have supplied the patches here, and it's been managed smoothly.


One is due to getting a PAST improvement:

bump parrot revision to get directaccess support, use directaccess 
for most var lookups


We're currently in the process of redeveloping PAST so it's written in 
NQP, can do native types better, is more memory efficient and so forth, 
and that work will be in the NQP repository, which would have avoided a 
bump of this nature - but it was just one bump out of 20.


Which leaves the biggest group, which are a combination of a policy of 
targeting the latest Parrot in releases and wanting to have those using 
Rakudo from git testing against latest Parrot after sizable changes, so 
we can have faster feedback if there are problems, which would seem 
desirable for both Rakudo and Parrot devs.


bump parrot revision to 4.2.0 release

bump parrot revision
just to get some better testing of newer birds, no specific reason

bump parrot revision to something after the cont_reuse merge

bump parrot requirement to 4.1 release

bump parrot revision to get some testing

bump PARROT_REVISION to 3.11 release

bump parrot revision

Bump PARROT_REVISION

Bump to Parrot 3.10 release.

Bump to latest Parrot (not quite release yet) in order to get more 
testing against it.


bump PARROT_REVISION to after the green_threads merge to get some 
more testing


bump PARROT_REVISION

Granted some in this category aren't explicit about the reason why, so 
there's some error in the analysis here.



Rakudo should be able to run on any Parrot release within the past year
(at least). The fact that it can't is a sign of poor software. We need
to figure out what's broken and fix it. I'm happy to help. Highly
motivated too, as it would remove a regular source of irritation.
There seems to be a few things going on here. One is that we don't 
differentiate Parrot revision requirement updates that are must have 
from those where we're bumping it for development reasons rather than 
because it's a hard dependency. Another is that Rakudo's feature needs 
often drive feature additions to Parrot and drive some bug fixes too; it 
seems inevitable that Rakudo will want to quickly take advantage of them.


Generally, I think things are currently more -Odevelopment than 
-Odistribution. I agree that makes things harder for those working on 
distributions, and I'm interested to make things better - I want it to 
be as easy for people to get their hands on recent Rakudo releases, and 
having it packaged for distributions does help with that. On the other 
hand, it's also an accurate reflection of the current state of both 
projects: in need of development work, and optimizing for it.


Also just to check - are you packaging Rakudo compiler releases, or 
Rakudo distribution releases (which are the ones we more intend for 
packaging)? Mostly asking due to the timing of the email; we didn't do a 
distribution release for March (so last interested one to package was in 
Feb), and the next one is due this month.


Thanks,

Jonathan

Re: sound distribution practices

[Patrick R. Michaud]

On Sat, Apr 07, 2012 at 03:24:37PM -0700, Allison Randal wrote:
 These are things that Rakudo shouldn't care about. A bug-fix or
 performance enhancement in Parrot is good, but doesn't actually affect
 Rakudo's ability to build or run.

Sometimes it does.  See the flurry of difficulties we had last April
and May when Rakudo testing discovered that Parrot performance had 
declined by 100% over the previous several months (and Parrot
developers were completely unaware of it).

 Did the actual APIs change?  Different arguments required, or
 substantially different behavior so that there was absolutely no way
 Rakudo could run on both the old and new versions of Parrot? 

I can think of several instances where the APIs changed, such that
Rakudo could no longer run on an older Parrot or would require
substantial detection of which version of Parrot is being used
and change code generation or behavior accordingly.

 If so, then Parrot could be doing a better job of supporting 
 language development here, by preserving old APIs.

  One is due to getting a PAST improvement:
 [...]
 This is eager adoption of new features again. But, in this case I agree
 the fix is that PAST should move to NQP and out of the Parrot packages
 entirely. For one thing, having NQP depend on a library in Parrot that
 depends on NQP is nightmarish for packaging. 

FWIW, I don't think this circular dependency exists (Jonathan doesn't
think so either).  AFAIK, there's nothing in Parrot that has any sort 
of dependency on NQP.  (Note that there's a distinction between
nqp and nqp-rx; Parrot includes some nqp-rx stuff, but doesn't
make use of nqp.)

 Indeed, not enough detail there for much analysis. But, in general there
 is a difference between what you choose as your development process, and
 what you choose as your release process. It is very sensible to always
 test Rakudo against the latest versions of Parrot. But, that doesn't
 mean you can stop testing against older version of Parrot. The most
 important older versions to test against are the ones shipped in various
 distributions.
 [...]
 It would also be helpful if Rakudo and NQP adopted more strategies to
 keep the minimum required version as low as possible. Like soft
 launching new features so they're simply not available when they depend
 on a newer Parrot feature.

I will go back and test, but I'm willing to hazard a guess that
there are very few Rakudo releases that would be able to go very far back 
in Parrot's release history and still be functional, even with a sort of 
soft launching described here.  

For a recent and directly on topic example, take a look at 
https://github.com/perl6/nqp/commit/242f6e5997f6c454246fcf97b8a2a5d038d95931 ,
provided to NQP by a Parrot developer on March 5.  This commit means 
that subsequent versions of NQP and Rakudo are absolutely unable to
work with any version of Parrot prior to 4.2.0, because it's
an API change.  I also don't see any soft launch for this commit
that would make it easy for Rakudo/NQP to preserve access to
older versions of Parrot.

(Better would probably have been for Parrot to introduce a new opcode
with the correct order of arguments rather than changing the API of
an existing opcode, but that's not what happened here, and the API
change was not introduced at the request of Rakudo/NQP.  As far as
we can tell it came entirely from the Parrot development team.)

 I guess that raises the question for me of whether Rakudo is ready to be
 packaged. I don't have any trouble with Parrot packaging, but I do get a
 regular series of unusual requests from the Rakudo packagers. If the
 Rakudo project is totally focused on the use-case of downloading the
 source code or checking out from git and compiling from source, maybe
 it's just not ready for packaging.
 [...]
 I'm sure all the Rakudo packagers will agree with me that they'd really
 hate to remove it from Debian. But, if packaging isn't something Rakudo
 wants to support, then we shouldn't force the project into a different
 mindset. To give you an idea of what Debian packaging is looking for,
 take a skim through the upstream guide:

I think this line of thinking reaches the wrong conclusions.
What can be said with certainty is that for every Parrot release,
there is at least one corresponding Rakudo release that can make
use of that Parrot.  There's no reason to talk of Rakudo isn't ready
for packaging, because for any release of Parrot there is at least
one contemporaneous release of Rakudo that can make use of it.

What I suspect may be happening is that the Rakudo packagers
are being a little over-eager about trying to provide the
later versions of Rakudo, when there's not a packaged version
of Parrot that can support them.  In this case, Rakudo's official
suggestion would be for Rakudo packagers to stick to the most recent
version of Rakudo that is compatible with whatever release of Parrot
is available in that environment.  Since Parrot has a much slower
release and 

Re: sound distribution practices

[Patrick R. Michaud]

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.
 
 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.
 
 The first alternative is better, and will be the first preference. But
 it needs stable APIs from Parrot, so old Rakudo packages consistently
 work on newer versions of Parrot. This is mostly working, but the
 exceptions are pain points for packaging (we've got one coming up for 4.3).

Because Parrot bytecode is incompatible (both forward and
backward) between Parrot releases, doesn't the first alternative
also require the Rakudo package's requirements to be bound
tightly (=) to exactly one version of Parrot?

(I'm mainly seeking to improve/confirm my understanding of packaging
issues here.)

Pm