From: Samuel Mimram Date: Sat, 27 May 2006 12:09:33 +0000 (+0000) Subject: Some more doc. X-Git-Tag: archive/raspbian/4.08.1-4+rpi1~3^2~641^2~6 X-Git-Url: https://dgit.raspbian.org/?a=commitdiff_plain;h=adfcc531a6f8a18e98a81d36302f1692e2f7963a;p=ocaml.git Some more doc. --- diff --git a/appendix-resources.xml b/appendix-resources.xml index a7e130a9..ff4ccfc0 100644 --- a/appendix-resources.xml +++ b/appendix-resources.xml @@ -1,22 +1,6 @@ - - The &ocaml-force;'s website: http://pkg-ocaml-maint.alioth.debian.org/ - The &ocaml-force;'s mailing list: debian-ocaml-maint@lists.debian.org - - - - - - - - + The &ocaml-force;'s website: http://pkg-ocaml-maint.alioth.debian.org/ (it's an Alioth project) + The &ocaml-force;'s mailing list: debian-ocaml-maint@lists.debian.org (archives) diff --git a/appendix-svn.xml b/appendix-svn.xml new file mode 100644 index 00000000..7c3223cc --- /dev/null +++ b/appendix-svn.xml @@ -0,0 +1,85 @@ +
+ How to obtain a copy of the pkg-ocaml-maint SVN archive + + FIXME: to be filled in + +
+ +
+ Structure of the pkg-ocaml-maint SVN archive + + We keep all files of the debian subdirectory under svn control, and +upstream only as a compressed tarball. The rationale behind this is +that changes to upstream files should be managed by the dpatch patch +manager. Hence, all the diffs to upstream files are kept in a +subdirectory of debian/, and it is not necessary to manage upstream on +file-by-file basis. + + + +The structure of the pkg-ocaml-maint svn archive is as follows, where +generic names are indicated in angular brackets [ .. ], and where the +contents of subdirectories not directly relevant for package management +are not detailed: + + tags + packages + [package1] + [version1] + [version2] + ... + [package2] + [version1] + ... + ... + projects + test + trunk + packages + [package1] + trunk + debian + upstream + [upstream-tarball-version1] + [upstream-tarball-version2] + ... + [package2] + ... + policy + projects + tools + + +
+ +
+ How to add a new package to the SVN archive + + Place yourself in the directory trunk/packages of your working copy of + the svn repository. Create a directory with the same name as your + source package (let's say, my-package), and subdirectories "upstream" + and "trunk". Put the current upstream tarball in "upstream", and the + current debian directory with all its relevant files in "trunk". This + should now look like this: + + trunk/packages/my_package + upstream + my_package_1.2.3.orig.tar.gz + trunk + debian + changelog + control + copyright + patches + 00_list + 01_patch1.dpatch + ... + ... + + + + + If everything is in order you can do a "svn add my_package" from the +"trunk/packages" directory, and eventually "svn commit". + +
diff --git a/appendix-transition.xml b/appendix-transition.xml deleted file mode 100644 index 80a402f8..00000000 --- a/appendix-transition.xml +++ /dev/null @@ -1,6 +0,0 @@ -
- Packages which can be binNMUed - - blah - -
diff --git a/chapter-generalities.xml b/chapter-generalities.xml index 68b6ef35..18e355f4 100644 --- a/chapter-generalities.xml +++ b/chapter-generalities.xml @@ -62,7 +62,7 @@ - The ocaml-native-compilers package contains the OCaml compiler built in native mode (ocamlc.opt and ocamlopt.opt). Compiling with this version of the compiler is generally faster but, as explained before, the ocaml-native-compilers package is not available on every architecture. Packages should therefore never depend directly on this package. In order to build big programs and benefit from this natively built compiler, packages should depend on ocaml-best-compilers which itself depends on ocaml-native-compilers where available and on ocaml elsewhere. Since it is a virtual package, it cannot (yet) be a versioned dependency. The version dependency should thus be carried by the ocaml dependency. + The ocaml-native-compilers package contains the OCaml compiler built in native mode (ocamlc.opt and ocamlopt.opt). Compiling with this version of the compiler is generally faster but, as explained before, the ocaml-native-compilers package is not available on every architecture. Packages should therefore never depend directly on this package. In order to build big programs and benefit from this natively built compiler, packages should depend on ocaml-best-compilers which itself depends on ocaml-native-compilers where available and on ocaml elsewhere. Since it is a virtual package, it cannot (yet) be a versioned dependency. The version dependency should thus be carried by the ocaml dependency. diff --git a/chapter-libpack.xml b/chapter-libpack.xml index b42111f8..606ae4ea 100644 --- a/chapter-libpack.xml +++ b/chapter-libpack.xml @@ -7,7 +7,7 @@ - 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; (or ocaml-base-nox-&ocaml-version;) as well as any other library needed. + 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; (or ocaml-base-nox-&ocaml-version;) as well as any other library needed. The versionned dependency on ocaml-base is important since libraries are binary incompatible between releases of OCaml: basically, a library compiled with OCaml 3.08 cannot be used with OCaml &ocaml-version;. @@ -39,12 +39,6 @@ -
- Handling dependencies on OCaml - - -
-
Paths for libraries @@ -57,11 +51,48 @@ - If upstream developpers don't use this scheme, 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 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. + If upstream developpers don't use this scheme, 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 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. + +
+ +
+ Handling dependencies on OCaml + + Some parts of the package need to know the current version of OCaml. For example, libraries should be installed /usr/local/lib/ocaml/&ocaml-version;/. However, the version of OCaml should never be hardcoded in the package (&ocaml-version; here). This would make a binNMU impossible if the version of OCaml has changed. Instead .in files should be used where @OCamlABI@ is replaced at build-time by the current OCaml version. + + + + For example, the package ocaml-mad would normally contain a file libmad-ocaml-dev.install for installing files with dh_install, containing: + +usr/lib/ocaml/&ocaml-version;/mad/META +usr/lib/ocaml/&ocaml-version;/mad/*.a +usr/lib/ocaml/&ocaml-version;/mad/*.cm* +usr/lib/ocaml/&ocaml-version;/mad/*.ml* + + In order to avoid the explicit mention of the version of OCaml (&ocaml-version;), the package actually contains instead a file libmad-ocaml-dev.install.in which contains: + +usr/lib/ocaml/@OCamlABI@/mad/META +usr/lib/ocaml/@OCamlABI@/mad/*.a +usr/lib/ocaml/@OCamlABI@/mad/*.cm* +usr/lib/ocaml/@OCamlABI@/mad/*.ml* + + The string @OCamlABI@ is substituted at build-time by the version of OCaml. Here are the relevant parts of the debian/rules file: + +OCAMLABI := $(shell ocamlc -version) +OFILES := $(patsubst %.in,%,$(wildcard debian/*.in)) + +ocamlinit: + for f in $(OFILES); do sed -e 's/@OCamlABI@/$(OCAMLABI)/g' $$f.in > $$f; done + +config.status: ocamlinit configure + [...] + +.PHONY: build clean binary-indep binary-arch binary install ocamlinit + + + + + The only exception to this rule is the debian/control file, which should never be generated at build-time. As explained before, the dependency should nevertheless not hardcode the version of OCaml: the debian/control file should have a Depends: ocaml-base-nox-${F:OCamlABI} which is filled by a dh_gencontrol -s -- -VF:OCamlABI="$(OCAMLABI)" in the debian/rules file.
diff --git a/chapter-progpack.xml b/chapter-progpack.xml index 07dcee58..8e69607b 100644 --- a/chapter-progpack.xml +++ b/chapter-progpack.xml @@ -17,7 +17,7 @@ -
+
Bytecode and native versions of programs As explained before, native OCaml compilers are not available everywhere. For architecture having no native compiler, a bytecode version of the program should be provided. @@ -36,6 +36,6 @@ - Bytecode versions of the programs should depend on ocaml-base-nox-&ocaml-version; (or ocaml-base-&ocaml-version; the program either uses the Graphics or the LablTk module). In order for the package to be able to be rebuilt or even binNMUed without a change in the packaging, this version should not be really hardocoded in the debian/control file. Instead, the package should depend on ocaml-base-nox-${F:OCamlABI} and use OCAMLABI := $(shell ocamlc -version) and dh_gencontrol -s -- -VF:OCamlABI="$(OCAMLABI)" in the debian/rules file. + Bytecode versions of the programs should depend on ocaml-base-nox-&ocaml-version; (or ocaml-base-&ocaml-version; the program either uses the Graphics or the LablTk module). In order for the package to be able to be rebuilt or even binNMUed without a change in the packaging, this version should not be hardcoded in the debian/control file. Instead, the package should depend on ocaml-base-nox-${F:OCamlABI} and use OCAMLABI := $(shell ocamlc -version) and dh_gencontrol -s -- -VF:OCamlABI="$(OCAMLABI)" in the debian/rules file.
diff --git a/ocaml_packaging_policy.xml b/ocaml_packaging_policy.xml index f94a7d30..e22c6f8e 100644 --- a/ocaml_packaging_policy.xml +++ b/ocaml_packaging_policy.xml @@ -23,8 +23,8 @@ - + ]> @@ -49,13 +49,13 @@ &chapter-libpack; - - Managing version transition - &appendix-transition; - - &ocaml-force; resources &appendix-resources; + + + Using the SVN repository + &appendix-svn; +