Thomas Weber <tweber@debian.org> writes: > On Fri, Feb 24, 2012 at 09:37:26PM +0100, Sébastien Villemot wrote: >> /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. > > I'm not sure about the "no problem part". > On i386, the paths will loke like > /usr/lib/i386-linux-gnu/.../i486-pc-linux-gnu > so the numbers are different. > > So, will this work with multi-arch? I think so. It fulfills the most basic requirement for multi-arch, which is that arch-specific files should lie in an arch-specific path. And policy §9.1.1 states that this arch-specific path should be under /usr/lib/<triplet>. Of course, adopting this directory structure is not always a sufficient condition for making a package multi-arch, but it is obviously a necessary condition. Given the current state of the multi-arch spec, only runtime library packages can be fully multi-archifyied. Packages containing binary executables cannot yet be multi-archifyied, since there is no such thing as /usr/bin/<triplet>. Hence liboctave1 is the only Octave package that can be fully multi-archifyied at this stage (i.e. declared as "Multi-Arch: same"). But for consistency I think we should adopt the multi-arch directory layout for all our packages (and this is what debhelper 9 does by default). Note that I am willing to do the necessary packaging work if we decide to go down that road. It should be just about bumping to debhelper 9 and dynamically generating the relevant *.install files (using the dh-exec package for example). -- 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:
pgpAPuSHsO85s.pgp
Description: PGP signature