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
signature.asc
Description: Digital signature
