--- /srv/rebuilderd/tmp/rebuilderdUaILJN/inputs/dh-ocaml_3.5_all.deb +++ /srv/rebuilderd/tmp/rebuilderdUaILJN/out/dh-ocaml_3.5_all.deb ├── file list │ @@ -1,3 +1,3 @@ │ -rw-r--r-- 0 0 0 4 2026-07-01 16:38:57.000000 debian-binary │ -rw-r--r-- 0 0 0 1756 2026-07-01 16:38:57.000000 control.tar.xz │ --rw-r--r-- 0 0 0 196464 2026-07-01 16:38:57.000000 data.tar.xz │ +-rw-r--r-- 0 0 0 200032 2026-07-01 16:38:57.000000 data.tar.xz ├── control.tar.xz │ ├── control.tar │ │ ├── ./control │ │ │ @@ -1,12 +1,12 @@ │ │ │ Package: dh-ocaml │ │ │ Version: 3.5 │ │ │ Architecture: all │ │ │ Maintainer: Debian OCaml Maintainers │ │ │ -Installed-Size: 910 │ │ │ +Installed-Size: 914 │ │ │ Depends: quickjs, libjson-perl, libconfig-tiny-perl │ │ │ Recommends: debhelper, ocaml │ │ │ Suggests: git │ │ │ Provides: dh-sequence-ocaml │ │ │ Section: ocaml │ │ │ Priority: optional │ │ │ Multi-Arch: foreign │ │ ├── ./md5sums │ │ │ ├── ./md5sums │ │ │ │┄ Files differ ├── data.tar.xz │ ├── data.tar │ │ ├── file list │ │ │ @@ -15,15 +15,15 @@ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2026-07-01 16:38:57.000000 ./usr/share/doc/ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/ │ │ │ -rw-r--r-- 0 root (0) root (0) 1338 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/README.Debian │ │ │ -rw-r--r-- 0 root (0) root (0) 1 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/TODO │ │ │ -rw-r--r-- 0 root (0) root (0) 1301 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/changelog.gz │ │ │ -rw-r--r-- 0 root (0) root (0) 896 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/copyright │ │ │ -rw-r--r-- 0 root (0) root (0) 54788 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_policy.html │ │ │ --rw-r--r-- 0 root (0) root (0) 5820 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_policy.txt.gz │ │ │ +-rw-r--r-- 0 root (0) root (0) 9330 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_policy.txt.gz │ │ │ -rw-r--r-- 0 root (0) root (0) 25699 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_reference.html │ │ │ -rw-r--r-- 0 root (0) root (0) 4851 2026-07-01 16:38:57.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_reference.txt.gz │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2026-07-01 16:38:57.000000 ./usr/share/doc/ocaml/ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2026-07-01 16:38:57.000000 ./usr/share/doc/ocaml-base/ │ │ │ drwxr-xr-x 0 root (0) root (0) 0 2026-07-01 16:38:57.000000 ./usr/share/doc-base/ │ │ │ -rw-r--r-- 0 root (0) root (0) 590 2026-07-01 16:38:57.000000 ./usr/share/doc-base/dh-ocaml.ocaml-packaging-policy │ │ │ -rw-r--r-- 0 root (0) root (0) 663 2026-07-01 16:38:57.000000 ./usr/share/doc-base/dh-ocaml.ocaml-packaging-reference │ │ ├── ./usr/share/doc/dh-ocaml/ocaml_packaging_policy.txt.gz │ │ │ ├── ocaml_packaging_policy.txt │ │ │ │ @@ -410,8 +410,265 @@ │ │ │ │ containing the ocaml interpreter, and the bytecode of the program in a │ │ │ │ section which is removed when the program is stripped. For more │ │ │ │ information, see the bug 256900. Custom bytecode executable is a │ │ │ │ deprecated feature of OCaml -- for now they still exist but should be │ │ │ │ avoided. │ │ │ │ │ │ │ │ Bytecode programs should not be compiled for debugging, i.e. they │ │ │ │ - should not be compiled using the -g option to │ │ │ │ + should not be compiled using the -g option to ocamlc. │ │ │ │ + │ │ │ │ +Native versions of programs │ │ │ │ + │ │ │ │ + Native OCaml compilers are not available on all architecures. For │ │ │ │ + architectures missing native compiler, a bytecode version of the │ │ │ │ + program should be provided. Native code packages are specific to an │ │ │ │ + architecture, that is they have Architecture=any in the source package. │ │ │ │ + │ │ │ │ + The debian/rules file should build the native code executable if │ │ │ │ + supported on the architecture it is built on, and fall back to building │ │ │ │ + the bytecode version if no working native code compiler is available. │ │ │ │ + As a consequence, the rules of the section called “Bytecode packages” │ │ │ │ + also apply here. │ │ │ │ + │ │ │ │ + It is safe to consider that detection of native architecture means │ │ │ │ + availability of ocamlopt or ocamlopt.opt when building. │ │ │ │ + │ │ │ │ +Bytecode and native versions of programs │ │ │ │ + │ │ │ │ + This should be done only under exceptional circumstances. Packages │ │ │ │ + providing both native and bytecode versions of a program prog usually │ │ │ │ + name them respectively prog.opt and prog.byte and provide a symbolic │ │ │ │ + link prog to the best available version (generally prog.opt). Please │ │ │ │ + consult the rules of the section called “Bytecode packages” and the │ │ │ │ + section called “Native versions of programs”. │ │ │ │ + │ │ │ │ +Chapter 3. Packaging OCaml libraries │ │ │ │ + │ │ │ │ + Table of Contents │ │ │ │ + │ │ │ │ + Creating packages for OCaml libraries │ │ │ │ + Paths for libraries │ │ │ │ + Providing META files │ │ │ │ + Camlp4/Camlp5 │ │ │ │ + Documentation │ │ │ │ + │ │ │ │ +Creating packages for OCaml libraries │ │ │ │ + │ │ │ │ + A package which provides an OCaml library called xxx should be split as │ │ │ │ + follows: │ │ │ │ + * For libraries which are not purely programmed in OCaml (e.g. C │ │ │ │ + bindings), libxxx-ocaml should provide the shared library stubs │ │ │ │ + (dll*.so), and all other stuff needed to run a bytecode executable │ │ │ │ + that links into this library. It should depend on │ │ │ │ + ocaml-base-[ocaml-version] as well as any other library needed. The │ │ │ │ + versioned dependency on ocaml-base is important since libraries are │ │ │ │ + binary incompatible between releases of OCaml. │ │ │ │ + libxxx-ocaml packages should be in Section: ocaml. │ │ │ │ + If the library provides native plugins (*.cmxs) or is meant to be │ │ │ │ + dynamically loaded using the Dynlink library, those plugins, │ │ │ │ + relevant *.cmo or *.cma files, and the META file referencing them │ │ │ │ + should also be provided by this runtime package. │ │ │ │ + * libxxx-ocaml-dev should provide the rest of the library package, in │ │ │ │ + fact anything needed to develop programs using the library. If the │ │ │ │ + library uses other libraries or C libraries then this package │ │ │ │ + should depend on them. │ │ │ │ + libxxx-ocaml-dev should depend on its companion libxxx-ocaml │ │ │ │ + package (if any). The reason is that at compile time the OCaml │ │ │ │ + compiler will try to load the shared library stubs, aborting the │ │ │ │ + compilation in case of failure. Hence the development package is │ │ │ │ + useless if the corresponding stub package is missing. To ensure │ │ │ │ + compatibility the dependency among the two packages should be │ │ │ │ + strictly versioned. In order for the resulting packages to be │ │ │ │ + binNMU safe this requirement states that the dependency should make │ │ │ │ + use of a ${binary:Version} substitution variable. │ │ │ │ + Example 3.1. Dependency from a -dev package to its companion shared │ │ │ │ + library stub package (if any), from the pcre-ocaml package │ │ │ │ + Package: libpcre-ocaml │ │ │ │ + Architecture: any │ │ │ │ + Section: ocaml │ │ │ │ + Depends: ocaml-base-[ocaml-version], ${shlibs:Depends}, ${misc:Depends} │ │ │ │ + ... │ │ │ │ + │ │ │ │ + Package: libpcre-ocaml-dev │ │ │ │ + Architecture: any │ │ │ │ + Section: ocaml │ │ │ │ + Depends: ocaml-[ocaml-version], libpcre3-dev (>= 4.5), libpcre-ocaml (= ${bina │ │ │ │ +ry:Version}), ${misc:Depends} │ │ │ │ + Suggests: ocaml-findlib (>= 1.1) │ │ │ │ + ... │ │ │ │ + │ │ │ │ + libxxx-ocaml-dev packages should be in Section: ocaml │ │ │ │ + All OCaml bytecode libraries (*.cma) and bytecode object files │ │ │ │ + (*.cmo) should be compiled for debugging, i.e. they should be │ │ │ │ + compiled passing the -g option to ocamlc (or ocamlc.opt). │ │ │ │ + │ │ │ │ + Optionally, two other packages may be created: │ │ │ │ + * libxxx-ocaml-bin may include binaries provided by the library │ │ │ │ + source package if they are numerous. This package should conform │ │ │ │ + with the same regulations as other packages providing ocaml │ │ │ │ + programs. It is only needed to split off this package if there is a │ │ │ │ + significant number of programs included in the library, if not, the │ │ │ │ + programs should go into libxxx-ocaml-dev. │ │ │ │ + * libxxx-ocaml-doc may include any kind of documentation provided by │ │ │ │ + the library source package or as separate documentation. Again, if │ │ │ │ + there is only little documentation, they should go with the -dev │ │ │ │ + package. │ │ │ │ + │ │ │ │ + It is recommended that libraries use the -pack option to pack all the │ │ │ │ + modules provided by the library into one module. We don't think │ │ │ │ + upstream libraries will be moving to this scheme anytime soon (unless │ │ │ │ + we actively lobby for it) so this is just a recommendation for now. │ │ │ │ + │ │ │ │ + It is recommended that each library package ships a META file in order │ │ │ │ + to make the library usable via ocamlfind (see the Debian package │ │ │ │ + ocaml-findlib). See the section called “Providing META files” for more │ │ │ │ + information on this. │ │ │ │ + │ │ │ │ +Paths for libraries │ │ │ │ + │ │ │ │ + Libraries should be installed in /usr/lib/ocaml/ or in a subdirectory │ │ │ │ + of this directory. This includes in particular bytecode libraries │ │ │ │ + (*.cma), native libraries (*.cmxa, *.a), native plugins (*.cmxs), │ │ │ │ + bytecode object files (*.cmo), native object files (*.cmx, *.o), static │ │ │ │ + libraries (*.a) and META files. The only exception to this rule is for │ │ │ │ + shared libraries (dll*.so) which should be installed in │ │ │ │ + /usr/lib/ocaml/stublibs, as can it be seen in the │ │ │ │ + /usr/lib/ocaml/ld.conf file. │ │ │ │ + │ │ │ │ + If upstream developers already use a subdirectory of the OCaml standard │ │ │ │ + library path then this path should be preserved in the Debian package │ │ │ │ + but made relative to the standard library path of OCaml. Before using │ │ │ │ + the provided subdirectory, packagers should obviously check if there is │ │ │ │ + no subdirectory name clash with another OCaml library. │ │ │ │ + │ │ │ │ + If upstream developers do not use this scheme then packagers are │ │ │ │ + encouraged not to install this library in the standard library │ │ │ │ + directory. They should create at least a subdirectory per source │ │ │ │ + package (in order to avoid name clashes). Packagers should also │ │ │ │ + consider to do a larger separation by creating a subdirectory per │ │ │ │ + binary package (in order to avoid META name clash). A suggested rule to │ │ │ │ + choose the name for this subdirectory is to use either the package name │ │ │ │ + provided by the META of the upstream, or the name of the library │ │ │ │ + itself. │ │ │ │ + │ │ │ │ +Providing META files │ │ │ │ + │ │ │ │ + The ocaml-findlib provides a tool (called ocamlfind) to handle OCaml │ │ │ │ + libraries and store information about libraries dependencies, compiler │ │ │ │ + flags, linking options, etc. Meta informations regarding a library are │ │ │ │ + contained in files (usually one for each library), named META files, │ │ │ │ + contained in the library directory. The distribution of META files is │ │ │ │ + the best way to make more easy to use the Debian-specific organization │ │ │ │ + of libraries. Packages distributing META files should suggest the use │ │ │ │ + of ocamlfind, that is have a Suggest: ocaml-findlib. │ │ │ │ + │ │ │ │ + By default, ocamlfind will look for META in this order: │ │ │ │ + * /usr/lib/ocaml/METAS/ │ │ │ │ + * /usr/lib/ocaml/package/ │ │ │ │ + │ │ │ │ + If a library package creates its own subdirectory │ │ │ │ + /usr/lib/ocaml/package/ then the META file should be stored in that │ │ │ │ + directory. │ │ │ │ + │ │ │ │ + The naming scheme of META is pretty simple. │ │ │ │ + * If the META file is placed in the subdirectory of the package then │ │ │ │ + it should be called META. │ │ │ │ + * If the META file is placed in /usr/lib/ocaml/METAS/ then it should │ │ │ │ + be called META.packagename, where packagename is the name of the │ │ │ │ + subdirectory where the library is stored. │ │ │ │ + │ │ │ │ + For example, the META file for the lablgtk library is named META and │ │ │ │ + has path /usr/lib/ocaml/lablgtk/META, where /usr/lib/ocaml is the main │ │ │ │ + OCaml installation directory and lablgtk is the lablgtk library │ │ │ │ + directory. │ │ │ │ + │ │ │ │ + If upstream doesn't provide a META then packagers are encouraged to │ │ │ │ + create one. In this case, the META file should contain a comment like │ │ │ │ + this, so that developers will know that they shouldn't count on the │ │ │ │ + availability of a META file on non-Debian machines: │ │ │ │ + # This META file is delivered by the Debian distribution. │ │ │ │ + │ │ │ │ + Furthermore, the META file should be sent to the upstream authors in │ │ │ │ + order to have it included in future versions of the upstream source. │ │ │ │ + For more information about META files see the Findlib manual, at the │ │ │ │ + several META files provided by other packages (e.g. lablgtk, pxp, pcre, │ │ │ │ + netstring, lablgl, ...) or ask on the debian-ocaml-maint mailing list │ │ │ │ + for help. │ │ │ │ + │ │ │ │ +Camlp4/Camlp5 │ │ │ │ + │ │ │ │ + Actually, Camlp4 extensions should be processed just like standard │ │ │ │ + OCaml libraries. In particular, they should provide a META file. The │ │ │ │ + syntax extension should be contained in a syntax sub package. │ │ │ │ + │ │ │ │ + The naming convention of the package is to use the same naming as with │ │ │ │ + standard package, replacing -ocaml- by the syntax extension name, │ │ │ │ + -camlp4-. │ │ │ │ + │ │ │ │ + If a package contains at the same time syntax extension and libraries │ │ │ │ + then it is up to the maintainer to choose the most relevant name for │ │ │ │ + the package. Whatever the name chosen for the package, the other name │ │ │ │ + should be a Provide of the package. │ │ │ │ + │ │ │ │ + For example, consider the package sexplib310. It provides a syntax │ │ │ │ + extension and a library, which is the runtime support of the additional │ │ │ │ + function generated by the syntax extension. Since the most common use │ │ │ │ + of sexplib310 is through its syntax extension, the package is name │ │ │ │ + libsexplib-camlp4-dev and it also provide libsexplib-ocaml-dev. │ │ │ │ + │ │ │ │ + Camlp5 is an alternate pretty-printer and preprocessor for OCaml (which │ │ │ │ + is compatible with pre-3.10.0 version). Syntax extension are handled │ │ │ │ + through exactly the same scheme as for Camlp4 except that package name │ │ │ │ + use -camlp5- rather than -camlp4-. │ │ │ │ + │ │ │ │ +Documentation │ │ │ │ + │ │ │ │ + The documentation is a joint effort of The Debian OCaml Task Force and │ │ │ │ + upstream. There are many ways to have documentation: │ │ │ │ + * header files (*.mli), │ │ │ │ + * source files (*.ml), │ │ │ │ + * specific documentation provided by the upstream, │ │ │ │ + * OCamldoc generated documentation. │ │ │ │ + │ │ │ │ + This documentation should be browsable by different means, from the │ │ │ │ + most simple to the most complex one. At least, they should all be │ │ │ │ + readable with a simple text editor. Specific and ocamldoc generated │ │ │ │ + documentations should be provided in HTML format. │ │ │ │ + │ │ │ │ + You can generate ocamldoc-specific documentation by using the -dump │ │ │ │ + option of this command. By using this, you dump the intermediate │ │ │ │ + representation of the document that will be generated by ocamldoc. This │ │ │ │ + can be used to generate HTML documentation and manpages, by reloading │ │ │ │ + this file (using -load). │ │ │ │ + │ │ │ │ +Appendix A. Appendix │ │ │ │ + │ │ │ │ + Table of Contents │ │ │ │ + │ │ │ │ + Locally installing OCaml programs and libraries │ │ │ │ + │ │ │ │ +Locally installing OCaml programs and libraries │ │ │ │ + │ │ │ │ + Locally installed files are files that are installed directly by the │ │ │ │ + system administrator, in contrast to files installed through Debian │ │ │ │ + packages. Installation and use of locally installed OCaml related │ │ │ │ + programs is out of the scope of this document. However, in order to │ │ │ │ + have it work with a standard Debian installation, a local system │ │ │ │ + administrator should follow these guidelines: │ │ │ │ + * Executable files should be installed in /usr/local/bin. │ │ │ │ + * Shared libraries (for C bindings) should be installed in │ │ │ │ + /usr/local/lib/ocaml/stublibs/ │ │ │ │ + * Basically, every other file should be installed in │ │ │ │ + /usr/local/lib/ocaml/. This includes in particular bytecode │ │ │ │ + libraries (*.cma), native libraries (*.cmxa), bytecode object files │ │ │ │ + (*.cmo), native object files (*.cmx), native plugin object files │ │ │ │ + (*.cmxs), static libraries (*.a) and META files. │ │ │ │ + │ │ │ │ + The default configuration of ocamlfind (the OCaml library manager │ │ │ │ + recommended in Debian) first looks for a local installation of │ │ │ │ + libraries and then for libraries installed by Debian packages. │ │ │ │ + │ │ │ │ +Warning │ │ │ │ + │ │ │ │ + The + preceding any library in the -I of ocamlc or ocamlopt won't be │ │ │ │ + expanded to the local standard library path. You need to specify the │ │ │ │ + path entirely.