On Tue, Oct 13, 2009 at 04:08:38PM +0200, Stéphane Glondu wrote:
> Stefano Zacchiroli a écrit :
> > [...] it is not possible to have a (binary) package
> > on which you don't have material on which compute a checksum. [...]
> I don't understand this sentence. Can you --verbose?
Yes, sorry for the --quiet mode.
Sylvain's argument was that it is better to keep = ${binary:Version}
dependencies because you don't always have enough stuff in a given
binary package to understand the ABI exposed by that package. [1] I
considered the case that in my opinion is the most dangerous in that
respect, that is a package shipping only a .so. I think it is the most
dangerous because none of the OCaml-aware *info tool we have can extract
checksum information from it.
[1]Yes, Sylvain also has the point of "minimal packaging technique
change", if needed I'll reply to that separately
But also in that case, the fact that you associate -dev ABI to the
runtime part shields you against that problem. You do have a ABI to
associate even to a package containing only *.so.
> > The point is exactly to detect incompatibility among the two at load
> > level, before a segfault hits you. With the current solution we can
> > enforce compatibility between interfaces and .so at the dependency
> > level, but the OCaml runtime can't check anything.
>
> The OCaml runtime doesn't check anything at this point. It just "hopes"
> that the .so is the same as the one that was used for linking. dh_ocaml
> enforces that.
Yes, I was discussing that this is a problem that can/should be solved
at the OCaml level. This is independent from our dependency scheme,
pretty much as we now have separation between the checks done by the
linker and their enforcement by dh_ocaml dependencies. In the case of
.so loading we do enforce consistency at the dependency level, but the
OCam loader doesn't check anything.
> > Also, the above mechanism of computing ABI checksum for the -dev part
> > and assigning it to the runtime part looks like a hack to me because we
> > can't infer anything from the .so. Hack that we could remove if .so were
> > inspectable. ... but that's sci-fi for now :-)
> I don't agree when you say it is a hack. For me, it seems pretty clean
> and clear: dh_ocaml considers a "library" as a whole (libxxx +
> libxxx-dev). Dispatching files between the two binary packages is just a
> matter of policy and is not relevant in the checksum computation.
I agree that the choice is a matter of policy. But once the choice is
made (at the end of package build), the ABI exported by a given binary
package is a property _of_the_package_. In an ideal world, we should
compute an ABI only considering the package content and stick that ABI
in some way to a Provides.
I see the hack in the fact that, given we can't inspect .so, we stick to
packages containing only them an ABI checksum we computed from their
sibling packages. (Now that I think at it, I would agree that in the C
world the situation isn't any better: SONAMEs are unique for a whole
library and not for binary package. IMO the proper solution can be
better also in that part of the world.)
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu à tous ceux que j'aime
Attachment:
signature.asc
Description: Digital signature