[Pkg-octave-devel] Multi-archifying Octave

[Sébastien Villemot]

Thomas Weber <tweber at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-octave-devel/attachments/20120228/86bfa019/attachment.pgp>