Packaging of libraries

Daniel Dehennin daniel.dehennin at baby-gnu.org
Wed May 24 17:17:37 UTC 2017


Daniel Dehennin <daniel.dehennin at baby-gnu.org> writes:


[...]

> I'll read zef#117 until I understand and try to contribute and see with
> people on #perl6/#perl6-dev

As far as I understand, we have 2 choices:

1. provide pre-compiled files in Debian packages

2. pre-compile files at Debian package installation

Here are the benefits/draw backs I can find for both options.

Pre-compiled files in Debian packages
=====================================

This seems to be what ocaml and haskell are doing[1].

Benefits:

- reduce energy cost: the files are pre-compiled only once by Debian
  builders

- faster installation time: just installing the package and everything
  is done

- tracking of files by dpkg: no need to worry about cleaning files at
  removal

Draw backs:

- bin-NMU all packages when a new MoarVM/NQP/Rakudo break the ABI of
  .moarvm files. What about installing a -unstable perl6-<module> on a
  stable distribution without updating the whole MoarVM/NQP/rakudo?

- seems to make difficult to provide packages for multiple versions of
  perl6 compilers

- optimisation: pre-compilation can not take advantages of CPU features
  since they are not known.


Pre-compile files at Debian package installation
================================================

This is what Python does[2][3].

Benefits:

- ABI changes can be handled by hooks (dpkg triggers and/or Perl6
  specifics like Emacs)

- Supporting multiple versions of Perl6 compilers just requires the good
  scripts to trigger the pre-compilation of all modules for that
  compiler

- optimisation: if the compiler support it the pre-compilation can
  optimise for local CPU.

Draw backs:

- energy cost, the pre-compilation is done on every machines where the
  installation is done

- slower installation time: the pre-compilation is done locally

- tracking of pre-compiled files: dpkg can not help, it must be done by
  the hooks


I do not explore the opportunistic pre-compilation since a non root user
will not be able to write under /usr/share/perl6/precomp/

If we can pre-compile at package building time, it can be done at
installation but requires to track generated files to clean them like
Python does.

Now we need to decide which is the best for us.

Regards.

Footnotes: 
[1]  https://github.com/ugexe/zef/issues/117#issuecomment-288508561

[2]  https://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html#s-runtimes_hooks

[3]  https://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-byte_compilation

-- 
Daniel Dehennin
Récupérer ma clef GPG: gpg --recv-keys 0xCC1E9E5B7A6FE2DF
Fingerprint: 3E69 014E 5C23 50E8 9ED6  2AAD CC1E 9E5B 7A6F E2DF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 357 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-rakudo-devel/attachments/20170524/009548cc/attachment-0001.sig>


More information about the Pkg-rakudo-devel mailing list