pkg-config and rpm relocations

[Kevin Fox]

On Mon, 2010-04-05 at 12:16 -0700, Tollef Fog Heen wrote:
> ]] Kevin Fox 
> 
> | Option 1, I can just fix up the .pc file in the postinstall rpm hook.
> | This would work but feels a bit unclean.
> 
> This would break the checksums that RPM stores and so rpm -V would fail,
> would it not?

Thats the biggest reason I dislike that idea. It breaks things.

> | Option 2, pkg-config seems to already have some prefix relocation code
> | in it but its only enabled in Windows. Is there a reason for this?
> | Would it be acceptable to enable this on linux to follow the RPM
> | relocation semantics? They are slightly different then whats there
> | now, but wouldn't be hard to implement. I could probably whip up a
> | patch for this if someone is interested.
> 
> I am not yet convinced about relocatable shared libraries being useful
> and am quite wary of enabling any support for relocating
> libraries. Rebuilding is usually less work and doesn't cause weird
> errors.

Its a chicken and the egg problem. Its hard to get shared libraries
relocatable because the build system gets in the way. The build system
guys don't want to make the build system handle it well because few
shared library properly support it.

I am trying to convince some of my coworkers to switch to using
pkg-config for their current libraries. They have a requirement that
their libraries are relocatable currently, so they do work already. If I
can't fix pkg-config, or at least work around it using option 1, then
the number of users using pkg-config won't grow. I'm willing to submit a
patch to add the functionality, but I don't want to do so if it wont be
accepted.

> Please note that I'm not disputing that you can, in some cases, relocate
> libraries, but you can't always.

This is true. That is why RPM's by default are not relocatable unless
you tell RPM explicitly in the spec file that the RPM is safe to
relocate. In my case though, I have relocatable ones I want to support.

> I guess an option might be to allow it with a flag in the .pc file, but
> again, I'm not convinced relocation is something we necessarily want to
> support.
> 

So the way relocation is handled in RPM is that you have something like:
/prefix/lib/libfoo
/prefix/bin/bar
/etc/foo.conf

The prefix variable in the rpm is assigned prefix=/prefix.

If you do not relocate, the file tree is as listed above. If you do
change prefix, /prefix is stripped from the list, making:
/lib/libfoo
/bin/bar
/etc/foo.conf

and then the new prefix is prepended making the final install tree:
/opt/myrelocation/lib/libfoo
/opt/myrelocation/bin/bar
/opt/myrelocation/etc/foo.conf

I think, how I would approach this would be to come up with two new
variables:
relocatableroot=/
relocatableprefix=/usr

If these exist, then the package is relocatable, it should follow the
RPM semantics. Check to see if the pkgconfig file is relative to the
relocatableprefix. If it is not, then change relocatableroot to point to
the correct place, and set relocatableprefix = "". This would
automatically set any other variable properly that uses those two
variables. It is fairly simple to write, and leaves it up to people
writing .pc files to make sure they are relocatable.

How would something like that sound?

Thanks,
Kevin