[Fedora-packaging] how to force rpmbuild to use local libraries?

[Krzesimir Nowak]

On Fri, 2009-08-28 at 14:18 -0400, Tom "spot" Callaway wrote:
> On 08/28/2009 12:22 PM, Krzesimir Nowak wrote:
> > Hi,
> > 
> > I'm using Fedora 11, so all software in repository are stable ones, but
> > I'm developing a library using unstable versions of them (e.g. I have
> > now glibmm24 2.20, and I need it in version 2.21.3). I have those
> > unstable versions installed in my home directory (that is `~/usr/') and
> > I'm testing my library on them by using parallel environment provided by
> > `jhbuild shell'. I decided to build a package with rpmbuild, but it uses
> > `/usr/' path for everything (pkg-config files and such) even if I
> > execute it from my parallel environment, so building the package ends
> > quickly with message of unmet dependencies or in configure stage, when I
> > pass `--nodeps' option. My question is: is there a way to force rpmbuild
> > to use libraries in my home directory instead of those in `/usr/'?
> 
> Well, to be fair, rpmbuild isn't to blame here. The spec file probably
> has something like:
> 
> %configure --with-foo --with-bar
> 
> That simply invokes configure with a set of sane options (including
> pointing to the system library/binary paths). For example, on my rawhide
> x86_64 system, %configure evaluates to:
> 
> CFLAGS="${CFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
> -mtune=generic}" ; export CFLAGS ;
>   CXXFLAGS="${CXXFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
> -mtune=generic}" ; export CXXFLAGS ;
>   FFLAGS="${FFLAGS:--O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64
> -mtune=generic -I/usr/lib64/gfortran/modules}" ; export FFLAGS ;
>   ./configure --build=x86_64-unknown-linux-gnu
> --host=x86_64-unknown-linux-gnu \
> 	--target=x86_64-redhat-linux-gnu \
> 	--program-prefix= \
> 	--prefix=/usr \
> 	--exec-prefix=/usr \
> 	--bindir=/usr/bin \
> 	--sbindir=/usr/sbin \
> 	--sysconfdir=/etc \
> 	--datadir=/usr/share \
> 	--includedir=/usr/include \
> 	--libdir=/usr/lib64 \
> 	--libexecdir=/usr/libexec \
> 	--localstatedir=/var \
> 	--sharedstatedir=/var/lib \
> 	--mandir=/usr/share/man \
> 	--infodir=/usr/share/info
> 
> Now, if your spec file used "./configure" instead of "%configure", you
> could hardcode any of those paths into the spec that you want. It
> wouldn't be portable though. Even if that package built, it would still
> depend on things not packaged up, and complain on installation.

But using ./configure with manually set options still will use
pkg-config files from /usr/lib/pkgconfig instead of ~/usr/lib/pkgconfig.
So configure stage will fail. Of course, I could define PATH (and other)
environment variable before running ./configure, but that is not what I
want and that blasts any portability away.

> 
> As a possible alternative, if you can make packages for the unstable
> library dependencies, then you can build this package in a chroot where
> the unstable libraries are installed. Or, if the libraries have unique
> sonames, you should be able to have them both installed in system
> locations and eliminate the need for the chroot.
> 

It probably will be better if I just wait until newest versions of
libraries are packaged to rawhide (e.g gtkmm24 in rawhide is 2.17.2 and
upstream is 2.17.9). Then I'll try to install rawhide as a second OS (I
already failed at that once) and build a package there.

Thanks for response,
Krzem