Rafael Laboissiere <rafael@laboissiere.net> writes: > * Sébastien Villemot <sebastien.villemot@ens.fr> [2012-02-24 21:37]: > >> The only potential problem that I see is that Octave already uses some >> triplets under /usr/lib, which in addition happen to be different from >> the Debian triplets. So we would end up with something like: >> >> /usr/lib/x86_64-linux-gnu/octave/3.6.1/oct/x86_64-pc-linux-gnu/svd.oct >> /usr/lib/x86_64-linux-gnu/octave/packages/3.6.1/optim-1.0.17/x86_64-pc-linux-gnu-api-v48+/ >> >> Note that there are two triplets in the paths. >> >> Functionally this is not a problem, but it is a little ugly, since >> there is some sort of duplication. >> >> My question is: do you think it is desirable and, if yes, feasible to >> remove the Octave-triplet from those paths? > > I did not really follow the multi-arch discussison, but it seems to me > that it only regards the location of the shared libraries loaded by the > system loader (/lib/ld-linux.so.*). I may be wrong, but my guess is that > the files under /usr/lib/octave/ are not concerned, in particular because > the architecture-dependent *.oct files are already under the appropriate > triplet, as you mentioned above. If you look at /usr/lib/<triplet> on your system (testing or unstable), you will see that it contains already a lot of libraries and package-specific subdirectories. Also, the changelog of debhelper between compat levels 8 and 9 contains: Multiarch support. In particular, dh_auto_configure passes multiarch directories to autoconf in --libdir and --libexecdir. So by default debhelper 9 will put everything under /usr/lib/<triplet>, both Octave dynamic libraries and everything else that used to go in /usr/lib/octave. Therefore I am reasonably confident about what I said in my previous email. But we can still choose to ignore multi-arch at this stage, it is not yet a release-critical issue. Best, -- Sébastien Villemot Researcher in Economics & Debian Maintainer http://www.dynare.org/sebastien Phone: +33-1-40-77-84-04 - GPG Key: 4096R/381A7594
Attachment:
pgpwPhRVlEaCf.pgp
Description: PGP signature