On Fri, Feb 12, 2010 at 12:48:39AM +0000, Simon McVittie wrote: > Does this look OK for upload to experimental, and if not, what changes > are needed?
FWIW, it was an unintended consequence of the wording of the policy change
that static libs and .so symlinks are permitted in the multiarch dirs at
this point - I only had runtime components in mind and expected that the
bits in -dev packages would all wait until later when the could all be
changed at once.
But I can't actually see any way that this is harmful, so I guess it's ok.
> libgfshare.pc
> =============
> # Copyright (c) Daniel Silverstone <dsilv...@digital-scurf.org> 2006
> prefix=/usr
> exec_prefix=${prefix}
> libdir=/usr/lib/i486-linux-gnu
> includedir=${prefix}/include
> Name: libgfshare
> Description: Secret Sharing in gf(2^8) library.
> Version: 1.0.3
> Libs: -L${libdir} -lgfshare
> Cflags: -I${includedir}
We don't really want extra -L options passed to the build for every library
that's installed to the multiarch lib dir. Does pkgconfig filter these out?
Has anyone verified that these extra -L options don't cause libtool to add
wrong rpaths to resulting binaries?
> Files only in first set of .debs, found in package libgfshare-dbg
> -----------------------------------------------------------------
> -rw-r--r-- root/root /usr/lib/debug/usr/lib/libgfshare.so.1.0.3
Has anyone checked that gdb will succeed in finding debug symbols via the
multiarch paths? (I guess gdb handles these generically by prepending
/usr/lib/debug to the real object path, but probably should be
double-checked anyway)
Cheers,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
