On Sat, 2009-07-25 at 11:28 +0200, Mathieu Malaterre wrote: > On Fri, Jul 24, 2009 at 7:45 PM, Max Bowsher<maxb@f2s.com> wrote: > ... > >> It would be extremely nice too if all wrap language would adopt the > >> same convention. So that toolkit such as VTK/ITK/GDCM wrapping their > >> interface into multiple languages (namely: Tcl, Python, Java, C#) > >> could simply decide: > >> (1) Allow SONAME > >> (2) Use a directory convention libfoo-$SOVERSION/$NAME.so > >> > >> for packaging mutiple modules. > > > > It is unclear to me what you are trying to standardize. > > How does one install multiple version of the same python/java/cli module ? That depends on how you mean "multiple versions". A CLI assembly has a version number, much like a SONAME, burned into it. You can read back the value with "monodis --assembly": directhex@desire:/usr/lib/cli/ndesk-dbus-1.0$ monodis --assembly NDesk.DBus.dll | grep Version Version: 1.0.0.0 This version number, like a SONAME, doesn't necessarily reflect the actual version number of the software - it's more of a flag to mark binary compatibility between versions. If you want to make a library globally available (i.e. it's not just some internal lib for a single app) then you need to install it to the GAC, and we have a policy document regarding how to properly version things so they can go into the GAC: http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-gac-naming-versioning Specifically relevant here also is http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-file-locations which outlines file locations. Taking these two documents together, you CANNOT install "multiple versions" which identify themselves as ABI-compatible, as they would both need to go into the same location (/usr/lib/cli/libname-X.Y), and both need to go into the GAC with the same versions marked too. If these versions do NOT share a version number, then as you can see, they should cleanly install side by side - old rules regarding file conflicts from, say, .pc files notwithstanding: directhex@desire:/usr/lib/cli$ ls mysql-connector-net-* mysql-connector-net-5.0: MySql.Data.dll mysql-connector-net-6.0: MySql.Data.dll One possible further point to consider are policy files. Policy files are used where a library has a newer version hard-coded, but the ABI for an old version is still 100% intact (i.e. there are no missing methods or properties which an app expecting an old version would trip over). This CAN eliminate the NEED for multiple library versions - for example: directhex@desire:/usr/lib/cli/mono-addins-0.2$ gacutil -l | grep "Mono.Addins," Mono.Addins, Version=0.4.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 policy.0.2.Mono.Addins, Version=0.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 policy.0.3.Mono.Addins, Version=0.0.0.0, Culture=neutral, PublicKeyToken=0738eb9f132ed756 As you can see here, we have Mono.Addins with a hard-coded ABI version of 0.4.0.0, but policy files for 0.2 and 0.3 mean any apps expecting the 0.2 or 0.3 versions are still fine. Policy files are also covered in the policy manual.
Attachment:
signature.asc
Description: This is a digitally signed message part