Re: Directory Organization for Sub-Architectures?
> Yes, it's not a complete solution, but it could at least get the
> packages into the distribution.
They're already in the distribution, currently using various kinds of
workarounds:
- The Atari-only packages setsccserial and nvram check in their
preinst that the install machine is an Atari (via /proc/hardware).
- The {amiga,atari-,mac}-fdisk packages work together so that they
don't have common files, and they create (in postinst) a symlink
/sbin/fdisk -> $mach-fdisk if it doesn't exist yet, where $mach is
extracted from /proc/hardware.
> Rather than a seperate field, we could just seperate it with some
> character, for example `Architecture: m68k/amiga'. That actually has
> an advantage that running an old dpkg on an atari, for example,
> would just refuse to install. It would incorrectly install it if you
> did with a second Subarchicture field. A new dpkg running on amiga
> would accept both `Architecture: m68k' and `Architecure:
> m68k/amiga'.
I have had that idea of '/'-separated sub-archs, too :-) But I later
dropped that because I thought it could be hard to get that new
definition of Architecture: in all the other tools (dpkg-genchanges,
..., which all look at the Arch: field).
The case of a non-subarch-supporting dpkg could also be handled by
calling dpkg --assert-subarchs-supported in the preinst of packages
needing it.
Roman
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-devel-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: