CLI packaging: glue module location?

[smr99]

Hi,

I'm wondering where to install a shared lib associated with a library
assembly.  Specifically, gdcm is a C++ library wrapped using swig to
produce a C# interface.  Swig generates a bunch of .cs files that are
compiled to produce the assembly and, additionally, some glue code
compiled into a shared lib (.so).

The shared lib is not intended as a link library so it shouldn't
really be in /usr/lib but, rather, in a directory that all cli-based
programs have in their library path.  For example, similar glue code
modules for python modules can be placed in
/usr/lib/pymodules/pythonX.Y.  Is there such a directory for C#?  I
had a look at the CLI Policy document [1] but did not see any suitable
advice.

Thanks,
-Steve


[1] http://pkg-mono.alioth.debian.org/cli-policy/



_______________________________________________
Pkg-mono-devel mailing list
Pkg-mono-devel@...
http://lists.alioth.debian.org/mailman/listinfo/pkg-mono-devel

[smr99]

Hi again,

On Thu, Apr 09, 2009 at 11:07:19PM -0500, Steve M. Robbins wrote:

> The shared lib is not intended as a link library so it shouldn't
> really be in /usr/lib but, rather, in a directory that all cli-based
> programs have in their library path.  For example, similar glue code
> modules for python modules can be placed in
> /usr/lib/pymodules/pythonX.Y.  Is there such a directory for C#?  I
> had a look at the CLI Policy document [1] but did not see any suitable
> advice.

As often happens, right after sending a question like this, I find
that the answer was right there [1] in the document I had cited :-/

So ... is this advice still valid for the new mono layout [2] ?  And
for non-GAC stuff, should everything be in /usr/lib/package or
/usr/lib/cli/package?  The policy [2] is a bit confusing on that
point:

    3.1.2 File Locations

    The package's applications, libraries and meta-data must be
    installed into /usr/lib/upstream_package_name.

    [...]

    Never install native "glue" libraries into /usr/lib, instead
    install them at /usr/lib/cli/upstream_package_name-X.Y. When
    moving libraries update the references to the new location using a
    DLL Map. See the Mono DLL maps secion for an example.



Thanks,
-Steve


[1] http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-file-locations
[2] http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition




_______________________________________________
Pkg-mono-devel mailing list
Pkg-mono-devel@...
http://lists.alioth.debian.org/mailman/listinfo/pkg-mono-devel

[Mirco Bauer-2]

Hi Steve and Mathieu,

On Thu, 9 Apr 2009 23:23:58 -0500
"Steve M. Robbins" <steve@...> wrote:

> Hi again,
>
> On Thu, Apr 09, 2009 at 11:07:19PM -0500, Steve M. Robbins wrote:
>
> > The shared lib is not intended as a link library so it shouldn't
> > really be in /usr/lib but, rather, in a directory that all cli-based
> > programs have in their library path.  For example, similar glue code
> > modules for python modules can be placed in
> > /usr/lib/pymodules/pythonX.Y.  Is there such a directory for C#?  I
> > had a look at the CLI Policy document [1] but did not see any
> > suitable advice.
>
> As often happens, right after sending a question like this, I find
> that the answer was right there [1] in the document I had cited :-/
>
> So ... is this advice still valid for the new mono layout [2] ?

Yes, the Mono 2.0 transition was more about package name layout, and to
link everything against CLI 2.0, not about file structure layout.

>  And
> for non-GAC stuff, should everything be in /usr/lib/package or
> /usr/lib/cli/package?  

§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.

That means the gluelib should go in /usr/lib/packagename (while
packagename is not strongly defined btw) .

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).

Is the library you are packaging really API unstable? Unversioned
(non-GACed) packaging should be only done if really needed.

> The policy [2] is a bit confusing on that
> point:
>
>     3.1.2 File Locations
>
>     The package's applications, libraries and meta-data must be
>     installed into /usr/lib/upstream_package_name.
>
>     [...]
>
>     Never install native "glue" libraries into /usr/lib, instead
>     install them at /usr/lib/cli/upstream_package_name-X.Y. When
>     moving libraries update the references to the new location using a
>     DLL Map. See the Mono DLL maps secion for an example.

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.

>
>
>
> Thanks,
> -Steve
>
>
> [1]
> http://pkg-mono.alioth.debian.org/cli-policy/ch-packaging.html#s-file-locations
> [2] http://wiki.debian.org/Teams/DebianMonoGroup/Mono20Transition
>
>

--
Regards,

Mirco 'meebey' Bauer

PGP-Key ID: 0xEEF946C8

FOSS Developer    meebey@...  http://www.meebey.net/
PEAR Developer    meebey@...     http://pear.php.net/
Debian Developer  meebey@...  http://www.debian.org/


_______________________________________________
Pkg-mono-devel mailing list
Pkg-mono-devel@...
http://lists.alioth.debian.org/mailman/listinfo/pkg-mono-devel

[malat]

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@...> 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
...

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).
How about gdcm_csharp.dll ? Is this something people will be comfortable with ?

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

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

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

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

Thanks again !

--
Mathieu

_______________________________________________
Pkg-mono-devel mailing list
Pkg-mono-devel@...
http://lists.alioth.debian.org/mailman/listinfo/pkg-mono-devel

[Mirco Bauer-4]

On Mon, 18 May 2009 18:06:02 +0200
Mathieu Malaterre <mathieu.malaterre@...> 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@...>
> 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:
http://pkg-mono.alioth.debian.org/cli-policy/ch-mono.html#s4.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
that)

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

>
> Thanks again !
>

You are welcome.

PS: for new topics, please use the debian-cli mailing list for this! :)
--
Regards,

Mirco 'meebey' Bauer

PGP-Key ID: 0xEEF946C8

FOSS Developer    meebey@...  http://www.meebey.net/
PEAR Developer    meebey@...     http://pear.php.net/
Debian Developer  meebey@...  http://www.debian.org/

_______________________________________________
Pkg-mono-devel mailing list
Pkg-mono-devel@...
http://lists.alioth.debian.org/mailman/listinfo/pkg-mono-devel