new version of ocaml packages ...
Hello, ...
I have found the reason for the provides not working (thanks go to jerome
marant).
It is in section 7.4 of the debian-policy about virtual packages :
If a dependency or a conflict has a version number attached then only real packages will
be considered to see whether the relationship is satisfied (or the prohibition violated,
for a conflict) - it is assumed that a real package which provides the virtual package is
not of the `right' version. So, a Provides field may not contain version numbers, and the
version number of the concrete package which provides a particular virtual package will
not be looked at when considering a dependency on or conflict with the virtual package
name.
It is likely that the ability will be added in a future release of dpkg to specify a
version number for each virtual package it provides. This feature is not yet present,
however, and is expected to be used only infrequently.
So, the current solution will not work, unless we are prepared to use ocaml | ocaml-base in
the depends field of every package.
I think, unless the above is fixed, that we should resort to the solution
provided by ralf, which consists of separating the ocaml-base files, and have
the ocaml package depend on it. But then, this could also justify following on
with the ocaml package split, and separating more stuff out (particluarly
camlp4 and labltk for now).
Another problem is that the replaces, conflicts and provides camlp4 apparently
don't remove the existing camlp4 package, which sounds like another bug in
dpkg behavior, or some unimplementezd functionality.
Now for the libraries, we could go the same way.
I thus propose this new scheme :
o The dlls will go into a library package (libocaml-xxx for example, or simply
libxxx ?)
o the rest of the stuff will go into a developpment package
(libocaml-xxx-dev ?) which will depend on the library package, and
conflicts, replaces and provides the old package name (xxx most often).
What do you think of this scheme, Should we go ahead with it ?
What about the naming scheme, should we call it libocaml-xxx or libxxx only ?
Also, in case of packages like lablgl, should we name it libocaml-gl, or
libocaml-lablgl ? We should ask the opinion of upstream about it. Naturally,
packages like labltk abd ocamltk, as well as mlgtk and lablgtk may force us to
make a choice for the libocaml-lablgl naming scheme.
For the above reason, i would strongly suggest we go for the libocaml-xxx
scheme, where the xxx is the old name of the package.
Now, i am not sure if the conflict/replace/provide part is really necessayr
here, or if it is just clutter we can remove now and fix packages depending on
these libraries, which should not be that numerous, i think, since anyway, the
dynamic libraries were not present prior to ocaml 3.04.
Finally, contrary to what i did tell to stefano, i will not be able to work on
this before new year (i am leaving again tommorow at noon), so we have until
january 3 do decide this.
After that, i will propose first the new ocaml package, together with, i hope,
a new /usr/lib/ocaml/ld.conf configuration script, file which i will move to
/etc/ocaml/ld.conf, as policy mandates.
Friendly,
Sven Luther
Reply to: