1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67
|
Updating the package
--------------------
Please make sure that moarvm and nqp are the most recent available
version to build rakudo. The versions should be identical.
You can run "perl debian/update-control.pl" so that this build-time
dependency requirements are added to control file. (this requires cme
and libconfig-model-dpkg-perl)
Why the strict runtime dependency on nqp ?
------------------------------------------
rakudo insists on using the exact version of nqp that was used for build.
So rakudo package has a dependency like (nqp = 1.2.3-1).
If nqp version does not match, rakudo bails out with something like:
$ perl6 -e 'say "Hello";'
Missing or wrong version of dependency 'gen/parrot/stage2/QRegex.nqp'
current instr.: '' pc 16152 (src/gen/perl6-pod.pir:6351) (src/Perl6/Pod.nqp:499)
called from Sub '' pc 1866 (gen/parrot/stage2/module_loader.pir:856) (src/vm/parrot/ModuleLoader.nqp:73)
called from Sub '' pc 1894 (gen/parrot/stage2/module_loader.pir:865) (src/vm/parrot/ModuleLoader.nqp:55)
called from Sub 'load_module' pc 1619 (gen/parrot/stage2/module_loader.pir:741) (src/vm/parrot/ModuleLoader.nqp:52)
called from Sub '' pc 196787 (src/gen/perl6-actions.pir:77528) (src/Perl6/Actions.nqp:7469)
called from Sub '' pc 1866 (gen/parrot/stage2/module_loader.pir:856) (src/vm/parrot/ModuleLoader.nqp:73)
called from Sub '' pc 1894 (gen/parrot/stage2/module_loader.pir:865) (src/vm/parrot/ModuleLoader.nqp:55)
called from Sub 'load_module' pc 1619 (gen/parrot/stage2/module_loader.pir:741) (src/vm/parrot/ModuleLoader.nqp:52)
called from Sub '' pc 367287 (src/gen/perl6-grammar.pir:127329) (src/Perl6/Grammar.nqp:4463)
called from Sub '' pc 1866 (gen/parrot/stage2/module_loader.pir:856) (src/vm/parrot/ModuleLoader.nqp:73)
called from Sub '' pc 1894 (gen/parrot/stage2/module_loader.pir:865) (src/vm/parrot/ModuleLoader.nqp:55)
called from Sub 'load_module' pc 1619 (gen/parrot/stage2/module_loader.pir:741) (src/vm/parrot/ModuleLoader.nqp:52)
called from Sub '' pc 758 (src/gen/perl6.pir:285) (gen/parrot/main.nqp:54)
(02:03:43 PM) timotimo: right, when nqp changes, rakudo immediately has to be rebuilt to go with the new nqp
(02:04:42 PM) domidumont: timotimo: I get that, but I did not change nqp. I just rebuilt it
(02:04:56 PM) [ptc]: my guess is that if one of the "supporting" packages needs a packaging fix, then all above need to be rebuilt and repackaged as well
(02:05:29 PM) domidumont: [ptc]: usually, not if the change is backward compatible
(02:06:28 PM) moritz: rakudo depends on exact versions of serialization contexts in nqp
(02:06:47 PM) moritz: so even if your fix adds a single object that's not exposed to the outside world, you need a rakudo rebuild
(02:07:23 PM) [ptc]: domidumont: I only meant in the Rakudo stack, since it looks like if one needs to rebuild nqp, then rakudo needs to be rebuilt too
(02:07:34 PM) domidumont: moritz: that sounds reasonable. But why impose a rebuild if the code does not change ?
(02:08:00 PM) moritz: domidumont: that's another nasty thing (more)
(02:08:06 PM) [ptc]: domidumont: however, that's how it *looks*, there are probably other considerations which mean that one can avoid rebuilds in some situations
(02:08:15 PM) timotimo: domidumont: ah, well, that's a change in rakudo's eyes :\
(02:08:27 PM) moritz: domidumont: nqp and rakudo identify serialization contexts via hashes
(02:08:51 PM) moritz: domidumont: now nqp is self-hosting, which means it must take care not to confuse the SC of the host and of the source when compiling itself
(02:09:26 PM) moritz: domidumont: which is why it introduces timestamps into these SCs, to avoid collision
(02:10:02 PM) moritz: domidumont, jnthn: I wonder if we could use command-line-supplyable identifiers instead of timestamps to distinguis the stages at the various builds
(02:10:24 PM) moritz: then a rebuild without a code change should get an SC with the same hash
(02:10:29 PM) timotimo: that could also give us shorter identifiers
(02:10:32 PM) timotimo: i'd like that
(02:10:40 PM) timotimo: save a tiny bit more ram and disk space
(02:12:18 PM) domidumont: Or the hash could be based on the actual source code (a bit like the code signatures computed by cons or scons)
(02:12:36 PM) timotimo: that would break the compiler vs compilee thing again
(02:13:00 PM) timotimo: because we always build the stage2 with the same code we've built the stage1 from
(02:13:24 PM) ***domidumont light bulb went on
(02:13:46 PM) moritz: domidumont: no
(02:13:55 PM) moritz: domidumont: because stage 1 and stage 2 have the same source code
(02:15:02 PM) domidumont: can the hash be salted with stage1 and then stage2 ?
(02:16:11 PM) moritz: something like that, yes
(02:16:25 PM) moritz: that's what I meant with command-line-supplyable identifiers
(02:16:52 PM) domidumont: ah ok.
(02:17:21 PM) timotimo: those identifiers could very well have - for example - the git commit identifier (plus a random string if the commit is "dirty")
So it looks like hairy dependency should be improved.
-- Dominique Dumont <dod@debian.org>, Mon, 25 Apr 2016 13:55:21 +0200
|