Re: multiple architectures
On Mon, Jun 23, 2003 at 06:03:27PM -0500, Adam Heath wrote:
> On Mon, 23 Jun 2003, Bart Trojanowski wrote:
>
> > In the recent thread 'dpkg and debhelper patches for lib64 support' we
> > talked about control files and associating architectures to packages
> > which those control files define.
> >
> > While the format of the control files has not yet been completely
> > defined, I would like to fork of into a related discussion.
> >
> > With s390/s390x and i386/amd64 it becomes more apparent that we need
> > dpkg to understand what architectures are valid on the current system.
> > Currently, dpkg --print-architecture is used everywhere to discover what
> > that architecture is.
>
> Checking for arch/os is the wrong way to do it. configure scripts check for
> features, not operating systems, so dpkg should do the same.
Agreed. But dpkg currently doesn't.
For the *BSD ports, the linux emulation support in the kernels make it
possible to run (some|most) Linux binaries, but libraries need special
handling. (Diversion of /lib and /usr/lib to someplace else when
installing libraries, for instance.) And dpkg needs to know that it can
install i386 packages, instead of only freebsd-i386 or netbsd-i386
packages.
> > However, on an amd64 machine one can install packages built for i386,
> > i486, i586, i686, and amd64. Yes, we don't currently have i486-i686 but
> > with the 'split' that's talked about on debial-devel@d.o it's a clear
> > win to have the notion of 'compatible' architectures.
> >
> > First off dpkg should be extended to support a --supports-architecture
> > option which would take on a single string parameter of an architecture
> > name. dpkg returns true or false depending on it's ability to install a
> > package compiled for said architecture on the running system.
>
> dpkg-architecture is where such support should be placed.
>
> > dpkg will discover if said architecture is valid by looking it up in a
> > file of supported architectures.
In an environment such as I described above, support for i386 on
freebsd-i386 would only be available if the linux-emulation is loaded into the
kernel, and the appropriate libraries are installed.
So dpkg-architecture could be wrong, if using a file of support
architectures.
> No, dpkg will only look at features. mmx, sse, cmpxch8(or whatever the
> menomic is).
I agree with this, and I think it should not be compiled into dpkg. This
could change, depending on what is installed. IIRC, ia64 is capable of
running i386 binaries, if the appropriate emulation is installed. So are
other systems. Long-term, it would be best if support for this sort of
thing were in dpkg.
> > On a rpm system one can specify 'arch_compat' entries in rpmrc. In this
> > configuration one can specify a relationship as follows:
> >
> > amd64: athlon
> > athlon: i686
> > i686: i586
> > i586: i486
> > i486: i386
> > i386: any
> >
> > In the above map the items on the right of the : can be multiple in
> > number. If Intel decided to release another x86 processor (let's call
> > it i786), and it became supported in an AMD extension to amd64 (let's
> > call it amd64a), we would have something like this:
> >
> > amd64a: amd64 i786
> > i786: i686
> > amd64: athlon
> > athlon: i686
> > i686: i586
> > i586: i486
> > i486: i386
> > i386: any
> >
> > Note that i786 cannot execute athlon binaries, but amd64a can execute
> > anything on the list.
> >
> > Note that the relationship above does not deal with package dependencies
> > like:
> >
> > Package: foo
> > Depends: lib64foo
> > Architecture: amd64
> > Description: 64 bit optimized version of foo
>
> Architecture: i386
> Depends: {mmx}, libc6 (>= 2.3)
> Conflicts: {sse}
>
> This is opposed to:
>
> Architecture: i386
> Depends: mmx
> Conflicts: sse
>
> The {} are used to escape from the normal package namespace, so that we don't
> conflict with any existing package names out there.
This seems like a good idea. In fact, I'd like to see it grow to replace
Architecture, since that approach is overly simplistic for the systems
that are possible now, and that likely will become more of a problem in the
future.
How far away from implemention is this?
> > That will have to be done by dpkg after the package architecture was
> > decided on being compatible with the host's architecture.
> >
> > Another useful option for dpkg (or perhaps some other tool) would be a
> > something that would list all architectures that can be built on the
> > current host. Something like this:
> >
> > $ dpkg --build-architectures
> > amd64 i686 i586 i486 i386
> >
> > The list could be based on something in /etc or by polling the compiler.
> >
> > This --build-architectures could potentially reduce the amount of
> > hard-coded rules in debian/rules files.
> >
> > I would be interested in hacking on dpkg to get this going... but before
> > I start I wanted to get some feedback from the people that know better
> > :)
This is problematic. There are debian packages for doing cross builds
for the Hurd on Linux. And I'm working on the capability of
cross-building native FreeBSD binaries from a glibc world. (Coexisting
libc's... "fun"!)
>From the looks of things, that may be "normal" on freebsd-i386, at least
for quite a while.
Now how does dpkg handle a system that can have libraries and packages
linked to one of three libc's? (BSD libc, glibc, and linux glibc.)
Note that the situation could actually get worse someday in the future,
if I ever get an Opteron or ia64 running Debian FreeBSD. 8-)
---Nathan
Reply to: