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) -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/1363618141.3438.12.camel@barnabas
