Tom Lane (tgl@xxxxxxxxxx) said: > > Port package to pkgconfig. Write foo-config script that calls pkg-config. > > (1) How many upstream projects will take back changes to make their > foo-config scripts depend on pkgconfig? I'm afraid this proposed > solution will mean we end up maintaining many local forks of foo-config. How many upstream projects will take back changes to make their FOO work with PAM? How many upstream projects will take back changes to make their FOO work with SELinux? How many upstream projects will take back changes to make their FOO work with udev? I'm not saying it's 100% the same, but there's a difference between mere packaging and integration, and this is one of those things. > (2) pkg-config isn't psychic either. As near as I can tell from a quick > read of its man page, the only way it can solve the problem is if > rpmbuild sets PKG_CONFIG_PATH to select either 32- or 64-bit libraries. > While that's adequate for solving our own build problems, it doesn't > help for people doing ordinary source builds of library-using software; > from their point of view foo-config is still broken. And this makes it > even less likely that any upstreams will take back the foo-config > changes, because the "solution" depends not only on pkgconfig but on a > worldview that says RPM is the only build environment that matters. You can always set your arch, with setarch or similar personality mechanisms. Regardless it's less broken than what we have now, and it solves the problems that we need to solve. I don't think waiting around for a perfect solution is the right answer. Bill
