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

Re: devel files and libraries in /lib


On 01/01/2011 Michael Biebl wrote:
> First of all, thanks Andreas and Jonas for getting libgcrypt and libgpg-error
> updated and moved to /lib.
> There is one remaining issue though about the devel files, I'd like to raise.
> For both libgpg-error-dev and libgcrypt11-dev you moved the .so symlink ,the *.a
> and *.la libtool files to /lib too.
> My original patch [1] for libcryptsetup (#604936) handled this diffently. It
> only moved the *.so.* files to /lib and kept all devel related files in
> /usr/lib. This looked like the right way to me.
> Afaicr I've never seen this documentented somewhere to do it this way and I'm
> wondering if this is indeed the agreed upon best practice and if we should
> document it somehow (policy, devref, whatever).
> Opinions?

funny enough, I raised this topic on #debian-devel at the same time. I
didn't find documentation about it as well, and thus where not sure
whether the development files for libraries in /lib belong to /usr/lib
or /lib.
A quick look at some packages gave the impression that there is no
standard way:

- most libdevel packages store the development .la files in /usr/lib
- a few store them in /usr/lib and link them from /lib (libacl1-dev,
  libattr1-dev, libdm0-dev, xfslibs-dev)
- a few store them in /lib (libnih-dev, libnih-dbus-dev, libsplashy1-dev)

a problem with storing the libdevel files in /usr/lib, is that you
cannot build the library with --libdir=/lib. If you do, the .la file has
libdir set to /lib, which is wrong if it is stored in /usr/lib.

Thus I guess the following is best practise:

- build with --prefix=/usr
- install .la file (if required due to reverse dependencies) and .so
  link to /usr/lib (just like the build system will do)
- install .so.X.X.X library file and .so.X link to /lib (other than the
  build system does)

Whatever the best practise may be, I agree with Michael that we should
document it somewhere (Policy and Debian Library Packaging Guide) and
fix the packages which don't do it correct yet.


Attachment: signature.asc
Description: Digital signature

Reply to: