On Mon, Jun 04, 2001 at 04:05:42PM -0600, Bdale Garbee wrote:
> I would love to see Debian adopt a solution that allows use of unmodified
> ia32 (i386 in Debian lingo) packages on ia64 systems... and which is general
> enough to handle the other multi-arch flavors we can anticipate.
So, how would the naming of packages work? Would you want to say:
apt-get install zlib1g zlib1g-ia64
to get both the i386 and ia64 packages installed? If so, this'd require
significant mods in the debian/rules of the packages you want to support
having 32 and 64 bits libs for.
Or would you rather say:
apt-get install zlib1g@i386 zlib1g
to get the i386 .deb? If so, you'd have to correct a fair number of tools
to cope with the possibility that there might really be two different
packages with the exact same name (dpkg, apt, and the testing scripts at
a minimum).
How would you indicate dependencies on the i386 versus the ia64 libs? All
dependencies from i386 debs would have to be satisfied by i386 debs,
clearly, but would the same apply to ia64 debs? Or could an ia64 deb
in non-free need the ia64 libc6 for some bins, and an i386 deb for
others? Does it make sense to have a policy requirement that 32 bit stuff
*always* gets put in the i386 architecture (where it's probably useful
to more people), even if that involves splitting a package into two?
If you can reasonably make the dependency trees completely separate (ie,
no ia64 deb's dependency can be satisfied by an i386 deb, and vice-versa),
then at least from testing's point-of-view, there's no problems with using
the same name for i386 and ia64 debs. From apt and dpkg's point-of-view,
getting Replaces: and Conflicts: right could be tricky. From dselect
and deity's point-of-view, a pleasant UI could be hard to get right.
Hrm. From testing's point-of-view, the only problem with that is that
is that you might end up with some i386 .debs not being installable on
an ia64 system.
So: do you want to try getting away with not allowing Depends: to cross
architectures? Conflicts: and Replaces: would still have to. Can sparc64
be made to work with a similar solution?
> - all shared library packages deliver files to architecture-specific
> paths on the target system. In other words, /lib-i386 instead
> of /lib (using whatever pathing convention feels right and could
> be adopted by a future FHS version).
There are more files affected than this. What should be done about
/usr/share/doc/zlib1g/copyright, which'll be provided by both zlib1g[i386]
and zlib1g[ia64]?
What, if anything, should happen if you try installing, say, ifupdown[i386]
and ifupdown[ia64]? There's no obvious way for dpkg/apt to know that zlib1g
is a library and you can install two versions of it, but that ifupdown isn't
and you can't. Should it fail to install and give you an error? Should one
set of binaries overwrite the others? (Which? What happens if you uninstall
later?)
If libraries in /lib should be renamed to be in /lib-i386, and
executables in /bin should just be the ia64 version, what should happen
with docs, examples, changelogs and/or copyrights? What about stuff in
/usr/lib/package which might be both architecture dependent and have
hardcoded paths in some binary or other?
A possibility might be to make dpkg go "Okay, this is an i386 .deb. Are
there any (a) libs in here, which I can translate to /lib-i386, or (b)
binaries which aren't already on the system? No? Fail and give an error.
Yes? Translate the libs, install the bins, rename the copyrights, cross
your fingers."
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``_Any_ increase in interface difficulty, in exchange for a benefit you
do not understand, cannot perceive, or don't care about, is too much.''
-- John S. Novak, III (The Humblest Man on the Net)
Attachment:
pgpAKBCj4sXmM.pgp
Description: PGP signature