[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Fwd: SONAME for python modules is bad?

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

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:

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-*


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, Version=, Culture=neutral,
policy.0.2.Mono.Addins, Version=, Culture=neutral,
policy.0.3.Mono.Addins, Version=, Culture=neutral,
As you can see here, we have Mono.Addins with a hard-coded ABI version
of, 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

Reply to: