Re: Helmut Grohne 2013-05-05 <[email protected]> > I tried to come up with a patch for this, but apparently this is not > totally trivial. One step required for gaining multi-arch is to change > --libdir to /usr/lib/<triplet>. This also changes > /usr/lib/postgresl/$(MAJORVER)/lib to > /usr/lib/<triplet>/postgresl/$(MAJORVER)/lib, but leaves > /usr/lib/postgresql/$(MAJORVER)/bin unchanged. I cannot tell whether > such a setup continues to work, but it is ugly to say the least. Also > moving anything from /usr/lib/postgresql/$(MAJORVER) to a multi-arch > path would cause breakage in postgresql-common, because it expects > non-multiarch paths in certain scripts. As it stands I am not convinced, > that changing --libdir is the route to success here and the only package > that really benefits from multi-arch is libpq5.
Hi Helmut, thanks for looking into this. This will unfortunately also break any extension module that installs its .so files into /usr/lib/postgresl/$(MAJORVER)/lib because the server's libdir will then also be multi-archified, and the server won't file the .so files anymore. (Not tested, but I'd surprised if it wasn't the case.) Generally I'm in favor of multi-archifying the lib packages, but we need to make sure we don't mess things up. (The testsuite will probably need to grow some tests for this, too, unless we think we already have enough "it works"-style tests already.) We'd need to try it, but I think just moving our .so files around manually should work, though this is also a pretty ugly solution because it won't work with static debian/*.install files. (And if we do this, I need to find a way how to auto-revert this for the squeeze suite on apt.postgresql.org...) Christoph -- [email protected] | http://www.df7cb.de/
signature.asc
Description: Digital signature
