{"diffoscope-json-version": 1, "source1": "/srv/reproducible-results/rbuild-debian/r-b-build.BkyJpxj9/b1/dh-ocaml_2.4_amd64.changes", "source2": "/srv/reproducible-results/rbuild-debian/r-b-build.BkyJpxj9/b2/dh-ocaml_2.4_amd64.changes", "unified_diff": null, "details": [{"source1": "Files", "source2": "Files", "unified_diff": "@@ -1,2 +1,2 @@\n \n- fd217c39ca350e6f532982f9afdb59a7 55816 ocaml optional dh-ocaml_2.4_all.deb\n+ 6f58894cd4e9e546b4bfe06f5d105285 62920 ocaml optional dh-ocaml_2.4_all.deb\n"}, {"source1": "dh-ocaml_2.4_all.deb", "source2": "dh-ocaml_2.4_all.deb", "unified_diff": null, "details": [{"source1": "file list", "source2": "file list", "unified_diff": "@@ -1,3 +1,3 @@\n -rw-r--r-- 0 0 0 4 2024-09-26 07:25:54.000000 debian-binary\n -rw-r--r-- 0 0 0 1744 2024-09-26 07:25:54.000000 control.tar.xz\n--rw-r--r-- 0 0 0 53880 2024-09-26 07:25:54.000000 data.tar.xz\n+-rw-r--r-- 0 0 0 60984 2024-09-26 07:25:54.000000 data.tar.xz\n"}, {"source1": "control.tar.xz", "source2": "control.tar.xz", "unified_diff": null, "details": [{"source1": "control.tar", "source2": "control.tar", "unified_diff": null, "details": [{"source1": "./control", "source2": "./control", "unified_diff": "@@ -1,12 +1,12 @@\n Package: dh-ocaml\n Version: 2.4\n Architecture: all\n Maintainer: Debian OCaml Maintainers \n-Installed-Size: 205\n+Installed-Size: 212\n Depends: libconfig-tiny-perl\n Recommends: debhelper, ocaml\n Suggests: git\n Provides: dh-sequence-ocaml\n Section: ocaml\n Priority: optional\n Multi-Arch: foreign\n"}, {"source1": "./md5sums", "source2": "./md5sums", "unified_diff": null, "details": [{"source1": "./md5sums", "source2": "./md5sums", "comments": ["Files differ"], "unified_diff": null}]}]}]}, {"source1": "data.tar.xz", "source2": "data.tar.xz", "unified_diff": null, "details": [{"source1": "data.tar", "source2": "data.tar", "unified_diff": null, "details": [{"source1": "file list", "source2": "file list", "unified_diff": "@@ -13,15 +13,15 @@\n drwxr-xr-x 0 root (0) root (0) 0 2024-09-26 07:25:54.000000 ./usr/share/doc/\n drwxr-xr-x 0 root (0) root (0) 0 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/\n -rw-r--r-- 0 root (0) root (0) 1338 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/README.Debian\n -rw-r--r-- 0 root (0) root (0) 1 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/TODO\n -rw-r--r-- 0 root (0) root (0) 1318 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/changelog.gz\n -rw-r--r-- 0 root (0) root (0) 896 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/copyright\n -rw-r--r-- 0 root (0) root (0) 54781 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_policy.html\n--rw-r--r-- 0 root (0) root (0) 2329 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_policy.txt.gz\n+-rw-r--r-- 0 root (0) root (0) 9330 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_policy.txt.gz\n -rw-r--r-- 0 root (0) root (0) 25674 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_reference.html\n -rw-r--r-- 0 root (0) root (0) 4851 2024-09-26 07:25:54.000000 ./usr/share/doc/dh-ocaml/ocaml_packaging_reference.txt.gz\n drwxr-xr-x 0 root (0) root (0) 0 2024-09-26 07:25:54.000000 ./usr/share/doc/ocaml/\n drwxr-xr-x 0 root (0) root (0) 0 2024-09-26 07:25:54.000000 ./usr/share/doc/ocaml-base/\n drwxr-xr-x 0 root (0) root (0) 0 2024-09-26 07:25:54.000000 ./usr/share/doc-base/\n -rw-r--r-- 0 root (0) root (0) 590 2024-09-26 07:25:54.000000 ./usr/share/doc-base/dh-ocaml.ocaml-packaging-policy\n -rw-r--r-- 0 root (0) root (0) 663 2024-09-26 07:25:54.000000 ./usr/share/doc-base/dh-ocaml.ocaml-packaging-reference\n"}, {"source1": "./usr/share/doc/dh-ocaml/ocaml_packaging_policy.txt.gz", "source2": "./usr/share/doc/dh-ocaml/ocaml_packaging_policy.txt.gz", "unified_diff": null, "details": [{"source1": "ocaml_packaging_policy.txt", "source2": "ocaml_packaging_policy.txt", "unified_diff": "@@ -162,8 +162,513 @@\n * If the execution of the program is very fast on typical application\n cases then the program contained in the package should be compiled\n to bytecode. Typical examples are hevea, or headache. See the\n section on bytecode packages.\n * Only in special cases, for instance when both versions provide\n different features, should a package contain programs both compiled\n to bytecode and native code. See the section on combined bytecode\n- and native code p\n+ and native code packages.\n+\n+Overview of the OCaml compilers\n+\n+Bytecode and native code compilers\n+\n+ The ocaml-native-compilers package contains the OCaml compiler\n+ executables built in native mode: ocamlc.opt, which produces bytecode,\n+ and ocamlopt.opt, which produces native code. Since the OCaml compilers\n+ are themselves written in OCaml this package exists only on\n+ architectures where compilation to native code is supported.\n+\n+ The ocaml package contains the OCaml compiler executables built in\n+ bytecode mode: ocamlc, which produces bytecode, and on architectures\n+ where compilation to native code is supported the compiler ocamlopt,\n+ which produces native code. It is important to understand that on\n+ architectures where compilation to native code is supported both\n+ packages contain compilers from OCaml to both bytecode and native code,\n+ the difference lies in the nature (installation size and execution\n+ speed) of the compiler executables.\n+\n+ Table 1.1. OCaml compilers\n+ Compiles to bytecode Compiles to native code\n+ Compiler executable in bytecode ocamlc ocamlopt\n+ Compiler executable in native code ocamlc.opt ocamlopt.opt\n+\n+ See the section called \u201cBytecode and native code\u201d on a discussion\n+ whether to produce native code or bytecode.\n+\n+Files used and produced by the OCaml compilers\n+\n+ The OCaml toolchain can produce or use the following kind of files:\n+ * pure bytecode executables (they can be recognized since they start\n+ with the shebang line #!/usr/bin/ocamlrun)\n+ * bytecode executables linked in custom mode. They are generated by\n+ ocamlc when the -custom flag is given at link time. Those\n+ executables are in ELF format and include both the final bytecode\n+ and the bytecode interpreter. The strip command should never be\n+ invoked on them since it will remove the bytecode part. Bytecode\n+ executables linked in custom mode are depreciated and should be\n+ avoided.\n+ * native executables (in ELF format)\n+ * bytecode libraries (*.cma, *.a)\n+ * native libraries (*.cmxa)\n+ * shared libraries (for C bindings) (dll*.so, lib*.so)\n+ * static libraries (for C bindings) (lib*.a)\n+ * bytecode object files (*.cmo)\n+ * native object files (*.cmx, *.o)\n+ * native plugin object files (*.cmxs)\n+ * configuration files for handling libraries with ocamlfind (META)\n+\n+Building packages using OCaml\n+\n+Findlib and ocamlfind\n+\n+ The Debian OCaml Task Force has chosen to fully support the findlib\n+ library. This is a suite of tools and libraries that help to manage\n+ OCaml libraries. This software is not specific to Debian and works on\n+ all platforms where OCaml is available. Through the years, this has\n+ become the de facto standard when relying on external libraries. The\n+ main frontend is called ocamlfind and provided by the package\n+ ocaml-findlib.\n+\n+ Even though compiling OCaml projects in Debian is still possible\n+ without ocamlfind it is highly recommended to use it.\n+\n+The OCaml system in Debian\n+\n+ There are three categories of OCaml packages in Debian:\n+ * Development packages contain OCaml objects required for the\n+ development or compilation of OCaml programs, or specifically for\n+ the creation of Debian packages containing OCaml programs.\n+ * Runtime packages contain OCaml objects necessary to run compiled\n+ programs. A runtime package is always associated with a development\n+ package.\n+ * Simple binary packages contain everything that does not fall into\n+ the two former categories. This includes bytecode and native\n+ executable of application programs, documentation, etc.\n+\n+ The ocaml package depends on all the basic packages needed to develop\n+ programs with OCaml. Here is the list of binary packages into which the\n+ OCaml system is organized:\n+ 1. The ocaml package contain the compiler and its libraries. It can be\n+ considered as a development package.\n+ 2. The ocaml-native-compilers package contains the OCaml compilers\n+ built in native mode (ocamlc.opt and ocamlopt.opt).\n+\n+Note\n+ The compilers themselves are built in native mode, nonetheless,\n+ both compilers for compiling toward bytecode and native code are\n+ contained in this package.\n+ 3. The ocaml-base package contains the interpreter and runtime\n+ libraries needed by bytecode programs compiled with OCaml (in\n+ particular, it contains the ocamlrun program). It can be considered\n+ as the runtime package associated to ocaml.\n+\n+Note\n+ ocaml-base contains also OCaml interface objects *.cmi, which are\n+ normally only in development packages because they are needed to\n+ run the ocaml toplevel from the package ocaml-interp.\n+ 4. The ocaml-interp package contains the toplevel system for OCaml\n+ (ocaml) which provides for an interactive interpreter of the\n+ language.\n+ 5. The ocaml-mode package contains the OCaml Emacs mode. This is the\n+ original Emacs mode provided with the OCaml upstream distribution,\n+ not to be confused with the tuareg Emacs mode which is in the\n+ package tuareg-mode.\n+ 6. The ocaml-source package contains the sources of the OCaml\n+ compiler.\n+ 7. The ocaml-compiler-libs package contains some internal libraries of\n+ the OCaml compiler (needed only in very rare cases, e.g. for\n+ developing languages which reuse OCaml internals).\n+\n+ Since libraries produced by OCaml are binary incompatible when compiled\n+ with different releases of OCaml, versioned virtual packages are also\n+ provided by packages at items (1), (2), (6) and (7):\n+ ocaml-[ocaml-version], etc.\n+\n+Choosing the right build dependencies\n+\n+ Compiling with native code versions of the compilers is generally\n+ faster than with compilers in bytecode. Unfortunately, the\n+ ocaml-native-compilers package is not available on every architecture.\n+ Packages should therefore never depend directly on this package. In\n+ order to build big programs and benefit from this natively built\n+ compiler, packages should depend on ocaml-best-compilers which itself\n+ depends on ocaml-native-compilers where available and on ocaml\n+ elsewhere. Since it is a virtual package, it cannot be a versioned\n+ dependency. The version dependency should thus be carried by the ocaml\n+ dependency. Note that dependency on ocaml-best-compilers is only\n+ necessary for really big programs for which compilation takes a lot of\n+ resources. For most small programs the compilers from the ocaml package\n+ are perfectly sufficient, and faster to install in a build environment\n+ than compiler executables in native code.\n+\n+Putting the right binary dependencies\n+\n+ Bytecode is specific to an upstream version of the OCaml system.\n+ Therefore, any package containing bytecode has to depend directly or\n+ indirectly on the packages providing the OCaml runtime system in\n+ precisely the version for which it was compiled (for instance,\n+ ocaml-base-[ocaml-version].) This is in particular the case for\n+ bytecode programs, but it is also the case for native code programs on\n+ the architectures on which there is no native code OCaml compiler, and\n+ on which the program will be actually compiled to bytecode (see the\n+ section on packaging native code programs). The exact dependencies of\n+ libraries packages are discussed in the chapter on library packaging.\n+\n+ In order for a package to be easily rebuild, or even binNMUed, in case\n+ of a transition from one OCaml version to another, these dependencies\n+ must not be hardcoded in debian/control. Instead, substitution\n+ variables must be used which are instantiated from the debian/rules\n+ file. See the discussion on build systems in the Debian OCaml\n+ Developers Reference for a discussion how this can be achieved.\n+\n+Dh_ocaml\n+\n+ The Debian OCaml Task Force has created a system to compute\n+ dependencies between OCaml packages and to ensure type-safe linking. It\n+ requires to use new substitution variables in debian/control:\n+ * Use the ${ocaml:Depends} substitution variable in the field\n+ Depends.\n+ * Add a field Provides: ${ocaml:Provides} in development and runtime\n+ packages.\n+\n+ More detailed information about this work can be found here.\n+\n+Integrating OCaml packages in Debian\n+\n+Location of OCaml directories\n+\n+ The root of all installed OCaml libraries is the OCaml standard library\n+ directory, which is /usr/lib/ocaml. This location can be obtained from\n+ the OCaml compiler by invoking it as ocamlc -where.\n+\n+Debian archive section\n+\n+ Packages intended for the development of OCaml programs or packages, as\n+ well as packages necessary for the execution of OCaml code (like\n+ runtime systems or libraries) should have their section set to ocaml.\n+\n+ End user applications that are not specifically aiming at OCaml\n+ development or execution support but just happen to be implemented in\n+ OCaml should have their section set according to their application\n+ domain (games, science, etc.). General development tools that are not\n+ specific to OCaml development go into section devel (example:\n+ headache).\n+\n+Documentation\n+\n+ Documentation relevant to programming in OCaml should be registered\n+ with doc-base in Section Programming/OCaml. This is the case for API\n+ documentation generated using ocamldoc. See the section on generating\n+ documentation.\n+\n+Chapter 2. Packaging OCaml programs\n+\n+ Table of Contents\n+\n+ Creating packages for OCaml programs\n+ Bytecode packages\n+ Native versions of programs\n+ Bytecode and native versions of programs\n+\n+Creating packages for OCaml programs\n+\n+ The source package should, if possible, use the name of the upstream\n+ package without modifications.\n+\n+ Packages containing executables (as opposed to libraries) may be\n+ produced by compiling to bytecode, native code, or both. See this\n+ discussion of which mode to choose.\n+\n+ Package containing only bytecode executable, native executable or data\n+ are simple binary package, as explained previously.\n+\n+Bytecode packages\n+\n+ A bytecode package has all its binaries compiled into bytecode. It\n+ depends on a package containing the OCaml runtime system. As a\n+ consequence, such a package has its architecture field set to all.\n+\n+ All bytecode executables should be linked dynamically against the\n+ shared libraries for C bindings, to not bloat the archive. That said,\n+ upstream authors often favor statically linked bytecode executables\n+ (ocamlc option -custom), because in this case they don't need to worry\n+ about the presence of the dll stub libraries. This is not a valid\n+ reason to use statically linked bytecode in a Debian package where\n+ package dependencies can fix this problem.\n+\n+ A bytecode package must depend on the runtime package that is required\n+ to run it. Typically, it should depend on ocaml-base-[ocaml-version].\n+ It can also depends on the virtual libXXX-ocaml-byte-ABCD provided by\n+ the runtime package libXXX-ocaml (see the section on binary\n+ dependencies).\n+\n+ A bytecode package must build-depend-indep on ocaml.\n+\n+ Bytecode programs which are compiled by ocamlc -custom must not be\n+ stripped. In particular, their package should be excluded from the\n+ dh_strip script. When compiled this way, an ELF executable is generated\n+ containing the ocaml interpreter, and the bytecode of the program in a\n+ section which is removed when the program is stripped. For more\n+ information, see the bug 256900. Custom bytecode executable is a\n+ deprecated feature of OCaml -- for now they still exist but should be\n+ avoided.\n+\n+ Bytecode programs should not be compiled for debugging, i.e. they\n+ should not be compiled using the -g option to ocamlc.\n+\n+Native versions of programs\n+\n+ Native OCaml compilers are not available on all architecures. For\n+ architectures missing native compiler, a bytecode version of the\n+ program should be provided. Native code packages are specific to an\n+ architecture, that is they have Architecture=any in the source package.\n+\n+ The debian/rules file should build the native code executable if\n+ supported on the architecture it is built on, and fall back to building\n+ the bytecode version if no working native code compiler is available.\n+ As a consequence, the rules of the section called \u201cBytecode packages\u201d\n+ also apply here.\n+\n+ It is safe to consider that detection of native architecture means\n+ availability of ocamlopt or ocamlopt.opt when building.\n+\n+Bytecode and native versions of programs\n+\n+ This should be done only under exceptional circumstances. Packages\n+ providing both native and bytecode versions of a program prog usually\n+ name them respectively prog.opt and prog.byte and provide a symbolic\n+ link prog to the best available version (generally prog.opt). Please\n+ consult the rules of the section called \u201cBytecode packages\u201d and the\n+ section called \u201cNative versions of programs\u201d.\n+\n+Chapter 3. Packaging OCaml libraries\n+\n+ Table of Contents\n+\n+ Creating packages for OCaml libraries\n+ Paths for libraries\n+ Providing META files\n+ Camlp4/Camlp5\n+ Documentation\n+\n+Creating packages for OCaml libraries\n+\n+ A package which provides an OCaml library called xxx should be split as\n+ follows:\n+ * For libraries which are not purely programmed in OCaml (e.g. C\n+ bindings), libxxx-ocaml should provide the shared library stubs\n+ (dll*.so), and all other stuff needed to run a bytecode executable\n+ that links into this library. It should depend on\n+ ocaml-base-[ocaml-version] as well as any other library needed. The\n+ versioned dependency on ocaml-base is important since libraries are\n+ binary incompatible between releases of OCaml.\n+ libxxx-ocaml packages should be in Section: ocaml.\n+ If the library provides native plugins (*.cmxs) or is meant to be\n+ dynamically loaded using the Dynlink library, those plugins,\n+ relevant *.cmo or *.cma files, and the META file referencing them\n+ should also be provided by this runtime package.\n+ * libxxx-ocaml-dev should provide the rest of the library package, in\n+ fact anything needed to develop programs using the library. If the\n+ library uses other libraries or C libraries then this package\n+ should depend on them.\n+ libxxx-ocaml-dev should depend on its companion libxxx-ocaml\n+ package (if any). The reason is that at compile time the OCaml\n+ compiler will try to load the shared library stubs, aborting the\n+ compilation in case of failure. Hence the development package is\n+ useless if the corresponding stub package is missing. To ensure\n+ compatibility the dependency among the two packages should be\n+ strictly versioned. In order for the resulting packages to be\n+ binNMU safe this requirement states that the dependency should make\n+ use of a ${binary:Version} substitution variable.\n+ Example 3.1. Dependency from a -dev package to its companion shared\n+ library stub package (if any), from the pcre-ocaml package\n+ Package: libpcre-ocaml\n+ Architecture: any\n+ Section: ocaml\n+ Depends: ocaml-base-[ocaml-version], ${shlibs:Depends}, ${misc:Depends}\n+ ...\n+\n+ Package: libpcre-ocaml-dev\n+ Architecture: any\n+ Section: ocaml\n+ Depends: ocaml-[ocaml-version], libpcre3-dev (>= 4.5), libpcre-ocaml (= ${bina\n+ry:Version}), ${misc:Depends}\n+ Suggests: ocaml-findlib (>= 1.1)\n+ ...\n+\n+ libxxx-ocaml-dev packages should be in Section: ocaml\n+ All OCaml bytecode libraries (*.cma) and bytecode object files\n+ (*.cmo) should be compiled for debugging, i.e. they should be\n+ compiled passing the -g option to ocamlc (or ocamlc.opt).\n+\n+ Optionally, two other packages may be created:\n+ * libxxx-ocaml-bin may include binaries provided by the library\n+ source package if they are numerous. This package should conform\n+ with the same regulations as other packages providing ocaml\n+ programs. It is only needed to split off this package if there is a\n+ significant number of programs included in the library, if not, the\n+ programs should go into libxxx-ocaml-dev.\n+ * libxxx-ocaml-doc may include any kind of documentation provided by\n+ the library source package or as separate documentation. Again, if\n+ there is only little documentation, they should go with the -dev\n+ package.\n+\n+ It is recommended that libraries use the -pack option to pack all the\n+ modules provided by the library into one module. We don't think\n+ upstream libraries will be moving to this scheme anytime soon (unless\n+ we actively lobby for it) so this is just a recommendation for now.\n+\n+ It is recommended that each library package ships a META file in order\n+ to make the library usable via ocamlfind (see the Debian package\n+ ocaml-findlib). See the section called \u201cProviding META files\u201d for more\n+ information on this.\n+\n+Paths for libraries\n+\n+ Libraries should be installed in /usr/lib/ocaml/ or in a subdirectory\n+ of this directory. This includes in particular bytecode libraries\n+ (*.cma), native libraries (*.cmxa, *.a), native plugins (*.cmxs),\n+ bytecode object files (*.cmo), native object files (*.cmx, *.o), static\n+ libraries (*.a) and META files. The only exception to this rule is for\n+ shared libraries (dll*.so) which should be installed in\n+ /usr/lib/ocaml/stublibs, as can it be seen in the\n+ /usr/lib/ocaml/ld.conf file.\n+\n+ If upstream developers already use a subdirectory of the OCaml standard\n+ library path then this path should be preserved in the Debian package\n+ but made relative to the standard library path of OCaml. Before using\n+ the provided subdirectory, packagers should obviously check if there is\n+ no subdirectory name clash with another OCaml library.\n+\n+ If upstream developers do not use this scheme then packagers are\n+ encouraged not to install this library in the standard library\n+ directory. They should create at least a subdirectory per source\n+ package (in order to avoid name clashes). Packagers should also\n+ consider to do a larger separation by creating a subdirectory per\n+ binary package (in order to avoid META name clash). A suggested rule to\n+ choose the name for this subdirectory is to use either the package name\n+ provided by the META of the upstream, or the name of the library\n+ itself.\n+\n+Providing META files\n+\n+ The ocaml-findlib provides a tool (called ocamlfind) to handle OCaml\n+ libraries and store information about libraries dependencies, compiler\n+ flags, linking options, etc. Meta informations regarding a library are\n+ contained in files (usually one for each library), named META files,\n+ contained in the library directory. The distribution of META files is\n+ the best way to make more easy to use the Debian-specific organization\n+ of libraries. Packages distributing META files should suggest the use\n+ of ocamlfind, that is have a Suggest: ocaml-findlib.\n+\n+ By default, ocamlfind will look for META in this order:\n+ * /usr/lib/ocaml/METAS/\n+ * /usr/lib/ocaml/package/\n+\n+ If a library package creates its own subdirectory\n+ /usr/lib/ocaml/package/ then the META file should be stored in that\n+ directory.\n+\n+ The naming scheme of META is pretty simple.\n+ * If the META file is placed in the subdirectory of the package then\n+ it should be called META.\n+ * If the META file is placed in /usr/lib/ocaml/METAS/ then it should\n+ be called META.packagename, where packagename is the name of the\n+ subdirectory where the library is stored.\n+\n+ For example, the META file for the lablgtk library is named META and\n+ has path /usr/lib/ocaml/lablgtk/META, where /usr/lib/ocaml is the main\n+ OCaml installation directory and lablgtk is the lablgtk library\n+ directory.\n+\n+ If upstream doesn't provide a META then packagers are encouraged to\n+ create one. In this case, the META file should contain a comment like\n+ this, so that developers will know that they shouldn't count on the\n+ availability of a META file on non-Debian machines:\n+ # This META file is delivered by the Debian distribution.\n+\n+ Furthermore, the META file should be sent to the upstream authors in\n+ order to have it included in future versions of the upstream source.\n+ For more information about META files see the Findlib manual, at the\n+ several META files provided by other packages (e.g. lablgtk, pxp, pcre,\n+ netstring, lablgl, ...) or ask on the debian-ocaml-maint mailing list\n+ for help.\n+\n+Camlp4/Camlp5\n+\n+ Actually, Camlp4 extensions should be processed just like standard\n+ OCaml libraries. In particular, they should provide a META file. The\n+ syntax extension should be contained in a syntax sub package.\n+\n+ The naming convention of the package is to use the same naming as with\n+ standard package, replacing -ocaml- by the syntax extension name,\n+ -camlp4-.\n+\n+ If a package contains at the same time syntax extension and libraries\n+ then it is up to the maintainer to choose the most relevant name for\n+ the package. Whatever the name chosen for the package, the other name\n+ should be a Provide of the package.\n+\n+ For example, consider the package sexplib310. It provides a syntax\n+ extension and a library, which is the runtime support of the additional\n+ function generated by the syntax extension. Since the most common use\n+ of sexplib310 is through its syntax extension, the package is name\n+ libsexplib-camlp4-dev and it also provide libsexplib-ocaml-dev.\n+\n+ Camlp5 is an alternate pretty-printer and preprocessor for OCaml (which\n+ is compatible with pre-3.10.0 version). Syntax extension are handled\n+ through exactly the same scheme as for Camlp4 except that package name\n+ use -camlp5- rather than -camlp4-.\n+\n+Documentation\n+\n+ The documentation is a joint effort of The Debian OCaml Task Force and\n+ upstream. There are many ways to have documentation:\n+ * header files (*.mli),\n+ * source files (*.ml),\n+ * specific documentation provided by the upstream,\n+ * OCamldoc generated documentation.\n+\n+ This documentation should be browsable by different means, from the\n+ most simple to the most complex one. At least, they should all be\n+ readable with a simple text editor. Specific and ocamldoc generated\n+ documentations should be provided in HTML format.\n+\n+ You can generate ocamldoc-specific documentation by using the -dump\n+ option of this command. By using this, you dump the intermediate\n+ representation of the document that will be generated by ocamldoc. This\n+ can be used to generate HTML documentation and manpages, by reloading\n+ this file (using -load).\n+\n+Appendix A. Appendix\n+\n+ Table of Contents\n+\n+ Locally installing OCaml programs and libraries\n+\n+Locally installing OCaml programs and libraries\n+\n+ Locally installed files are files that are installed directly by the\n+ system administrator, in contrast to files installed through Debian\n+ packages. Installation and use of locally installed OCaml related\n+ programs is out of the scope of this document. However, in order to\n+ have it work with a standard Debian installation, a local system\n+ administrator should follow these guidelines:\n+ * Executable files should be installed in /usr/local/bin.\n+ * Shared libraries (for C bindings) should be installed in\n+ /usr/local/lib/ocaml/stublibs/\n+ * Basically, every other file should be installed in\n+ /usr/local/lib/ocaml/. This includes in particular bytecode\n+ libraries (*.cma), native libraries (*.cmxa), bytecode object files\n+ (*.cmo), native object files (*.cmx), native plugin object files\n+ (*.cmxs), static libraries (*.a) and META files.\n+\n+ The default configuration of ocamlfind (the OCaml library manager\n+ recommended in Debian) first looks for a local installation of\n+ libraries and then for libraries installed by Debian packages.\n+\n+Warning\n+\n+ The + preceding any library in the -I of ocamlc or ocamlopt won't be\n+ expanded to the local standard library path. You need to specify the\n+ path entirely.\n"}]}]}]}]}]}