Bug#1023576: Need to change the way raku-api is built (will breaks modules)

[Dominique Dumont]

Hi

Following bug #1023576 and [1], the dependency between raku modules and rakudo 
version needs to be tightened.

Until now, every raku-module depends on raku-api-<rakuversion> (currently is 
raku-api-2022-07). The idea is to lock the pre-compiled files contained in a 
raku-module package to a specific rakudo version.

Turns out this is not enough. The pre-compiled files are specific to raku 
compiler id, which changes whenever nqp or rakudo sources are changed.

This source change occurred only on nqp or rakudo upgrades, until I had to 
patch rakudo source code to fix a bug (#1019579).

To fix this, I need to make sure that a module is dependent on a rakudo version 
with a matching compiler-id. 

I see no other solution than to change the way rakudo is built to include the 
compiler id in raku-api (well, only the first 8 chars, because compiler id is 
quite long).

I.e. the next version of rakudo will have this in its control file:

 Provides: raku-api-2022.07+a6fe09f2

And dh-raku-build will be modified to inject this dependency in raku modules. 
E.g.:

 Depends: raku-api-2022.07+a6fe09f2

So, the plan is:
- upload a new dh-raku (which will produce non installable raku module package 
until rakudo is updated)
- upload a new version of rakudo in experimental
- trigger a transition so that all raku modules are rebuilt with new rakudo 
and new dh-raku

Until the transition is complete, raku in Debian/unstable will be a mess.

If anyone has a better idea, I'm all ears ...

Dod

[1] https://github.com/rakudo/rakudo/issues/5099