On Sun, 2011-12-18 at 23:19 +0000, Arch Website Notification wrote:
> When randomly looking at files and directories, I
> found /usr/share/pkgconfig
> and though: "this ain't right"

For architecture-independent packages like the ones in
todo, /usr/share/pkgconfig is a perfectly valid place to store these
files. It's also in the default lookup path, so there's no reason to
rebuild all these packages.

On Mon, Dec 19, 2011 at 9:50 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
> n randomly looking at files and directories, I
>> found /usr/share/pkgconfig
>> and though: "this ain't right"
>
> For architecture-independent packages like the ones in
> todo, /usr/share/pkgconfig is a perfectly valid place to store these
> files. It's also in the default lookup path, so there's no reason to
> rebuild all these packages.

I had a look into this. According to pkg-config man both
/usr/{share,lib}/pkgconfig seem to be equally valid. As to my package
(udev) there is no clean way to move the pkgconfig files out of share
without also moving the man pages, so I'd rather not unless there is a
good reason (in which case I'll push a patch upstream).

-t

On Mon, 2011-12-19 at 10:15 +0100, Tom Gundersen wrote:
> On Mon, Dec 19, 2011 at 9:50 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
> > n randomly looking at files and directories, I
> >> found /usr/share/pkgconfig
> >> and though: "this ain't right"
> >
> > For architecture-independent packages like the ones in
> > todo, /usr/share/pkgconfig is a perfectly valid place to store these
> > files. It's also in the default lookup path, so there's no reason to
> > rebuild all these packages.
>
> I had a look into this. According to pkg-config man both
> /usr/{share,lib}/pkgconfig seem to be equally valid. As to my package
> (udev) there is no clean way to move the pkgconfig files out of share
> without also moving the man pages, so I'd rather not unless there is a
> good reason (in which case I'll push a patch upstream).

The reason for /usr/share/pkgconfig is mainly for multilib systems. The
32bit version of pkg-config will look into /usr/lib32/pkgconfig, the
64bit version whill look into /usr/lib/pkgconfig, or whatever libdirs
are in a distribution. For multi-arch packages like xkeyboard-config, it
would mean that it has to install two pc files. Instead of
that, /usr/share/pkgconfig is used.

Moving these files out of /usr/share means that our multilib repository
will have to fork packages that are architecture-independent.

BTW: As for /usr/share/pkgconfig/udev.pc: that .pc file is installed to
make clear where udev and its rules files are installed. As it's not a
library, there's nothing wrong with installing it there. Rule files are
quite the same on i686 and x86_64.

On Mon, Dec 19, 2011 at 10:26 AM, Jan de Groot <jan@jgc.homeip.net> wrote:
> BTW: As for /usr/share/pkgconfig/udev.pc: that .pc file is installed to
> make clear where udev and its rules files are installed. As it's not a
> library, there's nothing wrong with installing it there. Rule files are
> quite the same on i686 and x86_64.

Thanks for the explanation. Indeed you are right about udev. I was
hesitating for a moment as there are some architecture dependent libs
in /lib/udev. However, you are right udev.pc only covers the rule
files, and there is a separate architecture dependent libudev.pc
installed correctly in /usr/lib{,32}.

Cheers,

Tom