Bug#349318: libxft-dev: please do not export unnecessary libraries in xft.pc
On Sun, Jan 22, 2006 at 04:18:21AM -0800, Steve Langasek wrote:
> On Sun, Jan 22, 2006 at 10:57:12AM +0000, Daniel Stone wrote:
> > tags 349318 + fixed-upstream
>
> > On Sun, Jan 22, 2006 at 02:44:28AM -0800, Steve Langasek wrote:
> > > So, I suppose most of you have read
> > > <http://lists.debian.org/debian-devel-announce/2005/11/msg00016.html> about
> > > problems with packages depending on libraries that they don't use,
> > > particularly as relates to a potential libfreetype transition. One library
> > > that currently exposes freetype (and other libs) in its pkg-config .pc file,
> > > but shouldn't, is libxft.
>
> > > Please consider (and forward upstream) the attached patch which moves all of
> > > the library dependencies of libxft into the Libs.private variable in xft.pc,
> > > so that they aren't used on Debian except for static linking. I have not
> > > touched the 'Requires' field; even though packages which link to libXft
> > > should not need to link to libfontconfig, the pkg-config 'Requires' field
> > > controls both CPPFLAGS and LDFLAGS, and Xft includes fontconfig headers --
> > > unfortunately the pkg-config maintainer has not been convinced that CPPFLAGS
> > > from Requires.private should be propagated, despite the fact that there are
> > > many examples of this scenario in Debian... (this is bug #340904, for those
> > > who care.)
>
> > > FWIW, since September 2003 FreeType has supported pkg-config; however, I
> > > wouldn't recommend that Xft use pkg-config dependencies for libfreetype
> > > unless this Requires.private CPPFLAGS issue is resolved. :/
>
> > > Oh, also, there seems to be a pre-existing bug in this .pc file, in that
> > > -lX11 is specified for static linking, but -L/usr/X11R6/lib is not...
>
> > This has already been fixed in the modular tree (/cvs/xorg/lib, as
> > opposed to /cvs/xlibs). But I guess the CPPFLAGS scenario remains.
>
> Excellent. I don't suppose there's any ETA for this fix making it to
> unstable? I've found at least one package that could benefit from it, and I
> imagine there are plenty more.
I'm working on it. The mesa NMU will go in shortly, and after that I need
to figure out exactly how to handle the transition to FHS compliance. I'm
not entirely sure I'm happy with how Daniel did it (although I've yet to
look at it closely). I'm going to do a full analysis and post an RFC either
on debian-x or debian-devel about it. Once that's figured out, the libs,
drivers, and server can all go in to experimental, as they're finished
right now. Following that, there's some work to be done on bundling the
apps and packaging a few miscellaneous things that shouldn't take too long.
If it all works, I'm going to throw it to unstable and see how it goes.
I can't give you a real time line for this, since it's been mainly me doing
this on the Debian side so far, but I'm hoping to get all of modular in to
unstable within the next two or three months, but it's possible that it'll
go faster.
- David Nusinow
Reply to: