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