* Adam Heath <doogie@debian.org> [030623 19:22]:
> 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.
Sure, the requirement idea is grant. However, it does not solve the
issue of coexisting 32 and 64bit packages. When using my laptop I want
to install as many i686 packages as possible, buy on the server I want
to install amd64 packages. Installing i386 packages is a waste of the
CPU features.
Making all packages compiled for i*86 and amd64, be *_i386.deb's is
really not a good idea. There is no way for a 32bit binary package to
coexist with a 64bit package, since they are named the same. Sure their
Dependencies differ, but that is not clear until further inspection.
Consider other architectures in Debian it is clear to see ppc, ia64 or
arm, etc.
> > 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.
Yes, that makes sense.
> > 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).
That's not very intuitive for the end user. I am not sure how many
users know that they have MMX or even worse the CMOV instruction. And
how would you distinguish packages for CMOV-capable and non-capable
packages... say, after building them with dpkg-buildpackage?
> > 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}
I miss the point on how having SSE prevents your CPU from having MMX?
My AMD CPUs certainly support both.
Again I don't like the fact that there has never been a 386 processor
that supported MMX... and you are calling this package a 386 package.
It's not intuitive.
> The {} are used to escape from the normal package namespace, so that we don't
> conflict with any existing package names out there.
Good idea... and I like the dependency, but I disagree with the
architecture name.
Bart.
--
WebSig: http://www.jukie.net/~bart/sig/
Attachment:
pgp3OlVrk9ATa.pgp
Description: PGP signature