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

Re: Autoconf problem (Was: Packaging of aeskulap for Debian and dcmtk issue)



Am Mittwoch, den 14.11.2007, 23:37 +0100 schrieb Andreas Tille:
> On Tue, 13 Nov 2007, Juergen Salk wrote:
> 
> > Yup. The Debian dcmtk packages are compiled with libwrap support.
> > So you have to link against libwrap as well.
> 
> Thanks to Jürgens hint I got the package builded and nearly
> lintian clean (only minor issues).  But there is a problem which
> makes me wonder whether we have to do more.  Aeskulap installs
>     libconfiguration.{a,so}
>     libimagepool.{a,so}
> libraries to /usr/lib.  I wonder if we should release a package
> including dynamical and statical library.  The correct way would
> probably be to have a libaeskulap package containing the .so files
> and make the binary aeskulap package depend from it.

Why don't you make them convenience libraries (statically link them in),
so you don't have to install and separately package them?

lib_LTLIBRARIES becomes noinst_LTLIBRARIES - patch Makefile.am and run
automake to get the updated Makefile.in in your patch, then apply this
patch ... maybe you have to adjust some flags in other Makefile.am, but
this should be easy. We do this e.g. for gchempaint [1].

With this solution you also don't need to care about the naming of these
libraries ;)

> Moreover
> the .a files should go - including the needed header files -
> to a libaeskulap -dev package.

Is this package necessary for another package or are there developers
requesting the headers/static libraries? If not, IMHO you also don't
need to provide a Debian package for them. I mean, if someone wants
them, he can request them and then you can also introduce a -dev
package.

>  I really have no idea whether this
> makes sense at all and whether there is some need for such
> kind of libraries.  Alexander, do you think that the libraries
> might make sense for a user without Aeskulap?

That's IMHO the compelling question.

[1] http://svn.debian.org/wsvn/debichem/unstable/gchempaint/debian/patches/02_libgchempaint_convenience.dpatch?op=file&rev=0&sc=0

Regards, Daniel



Reply to: