Bug#770449: ITP, RFS for Caml Crush package
On 24/11/2014 18:01, Stéphane Glondu wrote:
> Le 21/11/2014 13:31, Thomas Calderon a écrit :
>> I submitted an ITP (#770296) and an RFS (#770449) request regarding the
>> packaging of Caml Crush.
>> [...]
>
> First remarks:
>
> 1. There is a "debian" directory in the upstream tarball, is that
> intentional? Keep in mind that is is ignored in favour of the
> one in .debian.tar.xz; the two agree for now, but this might
> change in the future.
> 2. Shouldn't the SOs of caml-crush-clients be installed in their own
> directory? Have you compared with existing PKCS#11 providers?
> Moreover, this might remove the need for Lintian overrides.
> 3. Consider the "Account Naming" section of [1].
> 4. Why do you enumerate architectures instead of using
> "Architecture: any"? Is the lack of arm64 on purpose?
> 5. I am suspicious about the package not using dh-ocaml. Especially on
> bytecode architectures.
>
> [1] https://wiki.debian.org/AccountHandlingInMaintainerScripts
>
>
> Cheers,
>
Hi,
Thanks for the initial review.
1. I have split the debian-related files from the master branch. I will
now use "upstream" and "debian" branches instead. Therefore, release
tarballs will not contain this directory.
2. You were right, there was no valid reason to have the SOs directly in
/usr/lib, I moved them to /usr/lib/<triplet>/caml-crush. This has indeed
the positive effect of suppressing the lintian issues.
3. I switched to the "Debian-pkcs11proxyd" system account and group.
4. Since we rely on OCaml native compilers, I switched from the
ocaml-nox build dependency to ocaml-native-compilers and have
"Architecture: any" instead.
5. Since Caml Crush does not (yet) support using bytecode-only
architecture, we rely on ocaml-native-compilers to restrict the
supported architectures.
I have uploaded a new version on mentors.debian.net
Regards,
--
Cordialement,
Thomas Calderon
Laboratoire architectures matérielles et logicielles
Sous-direction expertise
ANSSI
Tél: 01 71 75 88 55
Reply to: