Re: versioned libraries dependencies
On Tue, Nov 19, 2002 at 03:48:03PM +0100, Stefano Zacchiroli wrote:
> I propose to add versioned dependencies between libraries like those
> between libraries and the ocaml compiler/interpreter.
Ok for me, i was afraid to propose such, but if you feel it is needed.
> e.g.:
> - pxp build depends on ocamlnet
> - netclient build depends on ocamlnet
>
> rebuilding a new version of ocamlnet will cause pxp to become unusable
> (mitical "inconsistent assumption over bla bla" error) if it will not be
> rebuilt against the new ocamlnet package.
Mmm, ok, i suppose there is no other solution to this ?
> IMO the right solution is to have each ocaml library provide a versioned
> name (e.g. libocamlnet-ocaml-dev will provide
> libocamlnet-ocaml-dev-0.94) and the dependent libraries to build depens
> _and_ depend on it to avoid linking problems.
Mmm, yes, and then, this could help with the libdir change and the
migration between two different ocaml releases also. You just would need
to bump some kind of minor version when you rebuild for the new ocaml.
Or else, you could also include the caml revision in this version or
something such.
> So I propose to patch the ocaml packaging policy adding to it a
> statement regarding this.
Ok, no problem, and i will add it to the next ocaml package i do.
BTW, could you also look at the findlib entry in the policy document ?
> Two still open problems are:
> - can rebuilding a library changing only debian stuff (i.e. bumping only
> debian revision number) force the rebuilding of libraries depending on
> it? IOW when the md5sum of a library changes, only when the .cm* stuff
> itself changes or can it change also when, for example, the ocamlc
> compiler has been rebuilt?
Mmm, this is a problem. I suppose that it will change when the ocamlc
compiler change, but this should not happen in between major ocaml
releases, and if i have to add a bugfix to the ocaml compiler suite, i
will anyway bump the debian revision of the virtual provide like i will
do for the libdir change.
Also, it would be worth it to separate the ocaml compiler suite from the
ocaml libraries, or at least provide a virtual provide for the ocaml
libs.
What i think should be done here, is that when things change that the
maintainer know will be incompatible (because of a new version, or
because of patch he applied) he bumps either the version of the virtual
provide or the debian revision.
> - do we need this kind of stuff also for library shipping .sos or not?
> (i.e. do we need to put a Provide field also on non -dev packages?)
Don't know, we should need to ask. My guess is that the .sos are mostly
unversioned shared libs, and as thus should not cause any breakage,
unless you do incompatible changes in the stublibs code.
That said, the policy mandates that the .so package depends on the -dev
package, and uses the same version, mmm, maybe the policy don't say so,
i need to check, but i am busy until tomorrow evening. Anyway, here is
what i have for camlzip :
Package: libzip-ocaml
Version: 1.01-7.0.1
Depends: ocaml-base-3.06, libc6 (>= 2.3.1-1), zlib1g (>= 1:1.1.4)
...
Package: libzip-ocaml-dev
Version: 1.01-7.0.1
Depends: ocaml-3.06, zlib1g-dev (>> 1.1.4), libzip-ocaml (= 1.01-7.0.1)
Which i obtain by a :
Depends: ocaml-3.06, zlib1g-dev (>> 1.1.4), libzip-ocaml (= ${Source-Version})
Anyway, i don't believe it is good to have different versions of
libfoo-ocaml and libfoo-ocaml-dev installed at the same time. So i would
say go for it.
> I volunteer to patch the ocaml packaging policy after some agreement on
> this.
>
> If no one (or 'noone'?) objects I will try this stuff on next releases
> of ocamlnet, pxp, netclient.
Yes, please experiment it, and we can then see what came of this
experiment and apply it to the policy and all other packages (lablgl and
lablgtk are good candidates for this also).
Friendly,
Sven Luther
Reply to: