Re: Invalid dependencies (Re: Unhandled Exception: Mono.CSharp.InternalErrorException)
On Mon, 2013-03-18 at 15:34 +0100, Mathieu Malaterre wrote:
> Using monodis, I finally found out the issue. libactiviz.net-cil
> 1:1.0~git20111214-1 on amd64 is build against an older mummy release.
> Therefore we have:
>
> $ monodis --assemblyref /usr/lib/cli/ActiViz.NET/Kitware.VTK.dll
> [...]
> 2: Version=1.0.2.599
> Name=Kitware.mummy.Runtime
> Flags=0x00000000
> Public Key:
>
>
> While, if one recompiles+install, we get:
>
> $ monodis --assemblyref /usr/lib/cli/ActiViz.NET/Kitware.VTK.dll
> [...]
> 2: Version=1.0.3.599
> Name=Kitware.mummy.Runtime
> Flags=0x00000000
> Public Key:
>
>
> So the short solution is to request a binNMU of libactiviz.net-cil.
> But the long solution would be to have proper dependencies checking.
>
> Could some C# gurus let me know if there is anything missing in my
> activiz.net and/or mummy package to generate proper dependencies (and
> therefore have a btter long term solution) ?
>
> Thanks *very* much !
The first question is "are the two versions ABI-compatible?" - if the
ABI hasn't actually been broken (i.e. there are no removed methods or
properties) then you can include a GAC policy file which maps all
applications looking for the old ABI to the new ABI. For example, apps
with a moduleref for Mono.Addins 0.2.0.0, 0.3.0.0, 0.4.0.0, or 0.5.0.0
will still work with our 0.6.0.0 packages, thanks to policy files. The
command "mono-api-check" can be used to compare two assemblies to see if
their ABIs are compatible or not; the man page for dh_cligacpolicy shows
how to write a cligacpolicy file to do policy mapping, if appropriate.
If it is *not* ABI compatible, then you should bump the package name to
reflect it - i.e. libkitware-mummy-runtime1.0-cil should be bumped to
libkitware-mummy-runtime1.0.3-cil so both versions can be installed side
by side, and so linking applications use the correct one. This gets very
messy very quickly for libraries with a poor grasp of ABI stability - in
those cases you should abandon the GAC entirely, follow the rules for
non-GAC libraries
(http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-non-gac-library-packaging) and tweak all consuming applications to copy the library to the local install folder rather than try to use the GAC version, since the GAC cannot be trusted in this case (an example is libmono-cecil-cil, and the apps which bundle its contents during build)
Reply to: