Re: versioned libraries dependencies
On Wed, Nov 20, 2002 at 09:26:36AM +0100, Jérôme Marant wrote:
> Stefano Zacchiroli wrote:
>
> >On Wed, Nov 20, 2002 at 08:58:52AM +0100, J?r?me Marant wrote:
> >
> >
> >>Do you hav a concrete example? It looks like a problem with applications
> >>
> >>
> >
> >Just try to build an application that use both netclient and netstring
> >in current unstable.
>
> Do you have such an application tha I can try?
>
> >This is _not_ a problem with shared objects, this is a problem related
> >to the way ocaml ensure that type information are correct.
> >Each ocaml library keeps a table of md5sums of all .cmi against it was
> >built, if you try to use a .cmi with the same name but with a different
> >md5sum ocaml compiler will fail.
>
> When does a md5sum change?
When the .cmi changes.
I have noticed it does not happen everytime you change a file, but only
some times, i guess only when you change the type of one used function.
As an example, i have added a :
let sven = 0
in lablgl/gl.ml => no problem, since it wont affect the .cmi.
and a :
val sven : int
in lablgl/gl.mli
And sure it was triggered :
ocamlc -I Objets -I ../src/kernel/Objets -I ../src/interface/Objets -w p -I /usr/lib/ocaml/lablgtk -I /usr/lib/ocaml/lablgl -I
/usr/lib/ocaml/lablgtk -I /usr/lib/ocaml/lablgl -o sven lablgl.cma lablgtk.cma gtkInit.cmo lablgtkgl.cma unix.cma config.cmo kernel/kernel.cma embed.cmo gmap.cmo rules.cmo gmapRules.cmo parserValues.cmo lexer.cmo parser.cmo expr.cmo gmapImplementation.cmo state.cmo gmapDrawing.cmo ensemble.cmo viewer.cmo gmapCallBack.cmo interface/interface.cma main.cmo
Files /usr/lib/ocaml/lablgtk/lablgtkgl.cma(GlGtk)
and /usr/lib/ocaml/lablgl/lablgl.cma(Gl)
make inconsistent assumptions over interface Gl
make: *** [sven] Erreur 2
removing the :
val sven : int
and rebuilding lablgl makes all things work again.
> >Here we have to discuss which is the better why for debian to live with
> >this compiler (bug?)feature. IMO the best way is using versioned
> >dependencies between libraries so that a DD doesn't forget to rebuild
> >all libraries which depend on the one he is rebuilding.
> >
>
> But the problem occurs only when you want to rebuild an application, right?
Yes, here we are speaking about _build-dependencies_, and i have thought
a bit more bout it, and it seems to me that this is really only needed
in build dependencies, and thus only for the -dev packages (for build
dependencies).
The problem with the .so is another problem, which has not yet happened,
and cause less problem, altough maybe not so.
if the stub library changes, it will affect the .cmo containing the
external definitions, so either there are only compatible changes, or
the changes in the stublib also mean changes in the .ml file.
This will be a problem only if the changes affect a .cmi, that is if
there are no .mli hiding the changed external call.
In this case, we fall back to the previous situation, and the changes
are localized in the -dev package, which we handle as previously.
Now, what about an application linked with the older .so, which is
installed, and then you upgrade the .so.
Well, this is familiar ground, since something similar happens with the
so names of shared libs, but i don't really know if ocaml handles so
names correctly.
Anyway, for our debian packages, the app will continue to run correctly,
as long as the stubs it calls are still available and that :
o their type has not changed.
o their semantic has not changed. That is, they still do what they are
supposed to do.
The first will assuredly breadk the app, the second is more subtle.
So, i think all bytecode built packages (the -byte or whatever version)
of the apps, should depend on the virtual provide of the library they
were built with, and this virtual provide should be version bumped each
time an incompatible change in the stub lib happened. I don't know if
this is needed for the native code apps, since i think they statically
link to the stub library.
Let's sumarize :
o each libfoo-ocaml-dev package should provide a virtual version :
libfoo-ocaml-dev-1.2.3
o each libbar-ocaml-dev build-depending on the previous one should
build-depend on the virtual provide.
o if libfoo-ocaml-dev's .cmi changes in an incompatible way, it bumps
it virtual version to either 1.2.4 (new upstream) or 1.2.3-1 (debian
internal change).
o now, libbar-ocaml-dev will need to be re-uploaded with the new
dependency and rebuilt.
This solves problem #1.
o each stublib providing package libfoo-ocaml should provide a virtual
version libfoo-ocaml-1.2.3.
o each app linking with this stub lib should _depend_ on the virtual
version, _and_ build-depend on the developpment version.
o the depend on the stub lib is necessary only for the bytecode
packages, not (for now) for the nativecode versions.
We need to check this last statement, and plug in my bytecode/nativecode
proposal. I have tested it on spamoracle, and it works rather fine. We
have to approach the debian-policy group to make sure this will be
formalized and does not break in the future though.
And finally :
o the virtual version of both libfoo-ocaml-dev and libfoo-ocaml should
be keept in sync. Maybe we can do a more fine-grained thing here,
but it is not worth the effort, and less safe.
Ok, what do you think about this proposal ? Did i miss something or is
something blatantly wrong ?
Friendly,
Sven Luther
Reply to: