[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binaries for different architectures in debian packages



Hi Norbert,

On Tue, Jan 11, 2005 at 11:21:40AM +0100, Norbert Preining wrote:
> I am one of the contributers to the TeXlive project and we are in the
> process of packaging texlive as debian packages. Herein some questions
> have arisen, the most prominent ATM is:
> Are there any facilities to put binaries of different architectures
>   into debian packages?
>   Background: TeXlive is compiled for several different arch/os
>   combinations, while the data (texmf trees) can be shared between
>   all of them. We want the user to allow the exporting of the
>   texlive directory (via nfs and/or smb) and other clients to
>   use texlive straight ahead.
>   ATM we have binaries for alpha-linux, i386-freebsd4.10, 
>   i386-freebsd5.0, i386-linux, mips-irix6.5, powerpc-aix4.3.3.0,
>   powerpc-darwin6.8, sparc-solaris2.7, sparc64-linux, win32 and
>   x86_64-linux.

> Best would be (if this is allowed according to the policy) to put
> everything under
> 	/usr/share/texlive/
> where there are
> 		.../bin/<arch>-<os>/

No, this is a violation of the FHS, which is included by reference in Debian
policy.  You would, at a minimum, have to use /usr/lib instead of
/usr/share.

> and put symlinks from /usr/bin/xyz to
> /usr/share/texlive/bin/<arch>-<os>/xyz.

There is precedent for /usr/bin/foo -> /usr/lib/foo/foo-bin symlinks in
Debian, but I don't believe there's any precedent for creating
/usr/lib/foo/arch-os/ tree farms in a package.  (Unless you count gcc,
perhaps, but in that case the names refer to target architectures of the
toolchain, not host architectures that the binaries run on.) I think
deploying such a method in Debian would be ill-advised until we see what
the final shape of multi-arch is.

Even in that case, I don't think it's very consistent with Debian design
philosophy to have a monolithic package including binaries for other
architectures, which seems to be your intent.  It certainly wouldn't be
eligible for inclusion in Debian main in such a form.

-- 
Steve Langasek
postmodern programmer

Attachment: signature.asc
Description: Digital signature


Reply to: