[Debian-med-packaging] Bug#531181: Fwd: CLI packaging: glue module location?

Mathieu Malaterre mathieu.malaterre at gmail.com
Sat May 30 14:01:31 UTC 2009

Adding notes from Mirco Bauer to bug.

---------- Forwarded message ----------
From: Mirco Bauer <meebey at debian.org>
Date: Thu, May 28, 2009 at 11:45 PM
Subject: Re: CLI packaging: glue module location?
To: pkg-mono-devel at lists.alioth.debian.org, Mathieu Malaterre
<mathieu.malaterre at gmail.com>
Cc: "Steve M. Robbins" <steve at sumost.ca>

On Mon, 18 May 2009 18:06:02 +0200
Mathieu Malaterre <mathieu.malaterre at gmail.com> wrote:

> Hi Mirco,
>   Just an update. libgdcm-cil has been uploaded:
> http://packages.debian.org/unstable/libgdcm-cil
> On Fri, Apr 10, 2009 at 11:57 AM, Mirco Bauer <meebey at meebey.net>
> wrote: <...>
> > §3.3.1 Naming says:
> > "The package should be named libfoo-cil (without a version in the
> > package name) and libraries should not be installed into the GAC but
> > only into /usr/lib/packagename.
> Ok, we have right now:
> $ dpkg -L libgdcm-cil
> ...
> /usr/lib/libgdcm-cil/libgdcm.so
> /usr/lib/libgdcm-cil/gdcm_csharp.dll

Looks good for non-GACed libs.

> ...
> Apparently there is no strong policy for the naming convention of the
> actual gluelib: libgdcm.so (there might be a conflict once I start
> uploading the gluelib for the java wrapping, but that's a different
> story).

The name if the gluelib doesn't really matter, the consumer of the CLI
library will not use it in any way (directly).

> How about gdcm_csharp.dll ? Is this something people will be
> comfortable with ?

Hm? You wrote the C# binding for gdcm? Using C# in the lib name is
very wrong in all cases. The CIL bytecode can be used by any language
that targets the CLI. To give some examples: VB.NET, Boo, Nemerle (yes,
those are all in debian already :)).

There is a common prefix of nFOO (like nunit or nant) and for
bindings even more common is the suffix of FOO-sharp (not -csharp)
like gtk-sharp, gnome-sharp, evolution-sharp.

> > The Mono runtime is not fiddling with the LD_LIBRARY_PATH and thus
> > you have to hint the runtime where it can find the gluelib using
> > the DLL map that goes along with the assembly (CIL lib).
> Do you have a small document explaining how to do this ? I am a C++
> dev, and only did the C# wrapping, because users were starting to beg
> for a C# layer...

That's documented in the Debian CLI Policy §4.2:

You should take a look at that, it contains also many other interesting
bits (like naming).

> > Is the library you are packaging really API unstable? Unversioned
> > (non-GACed) packaging should be only done if really needed.
> API is stable, if not then this is a bug.

Then I wonder why you packaged it in an API unstable way then.
See §3.2 vs §3.3 of the Debian CLI Policy.

(well I can guess because of the GAC trouble or users not requesting

> > 3.1.2 is about the general location of files, while GAC and non-GAC
> > libs are overriding that definition in 3.2.1 and 3.3.1.
> Again, do you have a document explaining what I need to generate using
> gacutil ? so far I only provided gdcm_csharp.dll and libgdcm.so and
> people seemed happy with only those.

They will only be happy, if they _copy_ those 2 files into their
application directory, which isn't really that nice :)

If you want to ship that library in a GAC you have to sign that
library, and again that's explained in the Debian CLI Policy (I hope I
don't sound like I am repeating myself, eh :-P)

> As a side note, I am now generating the XML documentation (gmcs
> /doc:gdcm.xml). Where should this file go ?

Ok, that's a nice question now :) When you generate the XML file you
can use different tools to generate real docs (to be consumed by the
user). In Debian we use monodoc to do that. If want an example see the
source package of log4net, mysql-connector-net-5.0, nini, semweb or
smartirc4net. They all do that generation in the debian/rules file.

More information about the Debian-med-packaging mailing list