Re: multiple architectures
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.
> 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.
No, dpkg will only look at features. mmx, sse, cmpxch8(or whatever the
menomic is).
> 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.
> 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
> :)
I already have a patch that externalizes the arch compare stuff.
Reply to: