Re: additions to dpkg-architecture
Volker Grabsch <firstname.lastname@example.org> writes:
> Dear Debian Developers,
> I've been pleased to summarize some ideas for the general public.
> More details and sources can be found at the end of this mail.
> I'm not subscribed to all lists, so please CC any replies to me.
> I propose to add more CPU types to dpkg-architecture. In particular,
> I'd like to see the different i386 architectures there, i.e.
> i586, i686, k6, ...
> The dpkg-cross tool is currently only used for cross compiling
> applications. However, dpkg-cross is a more generic tool. The
> "dpkg-buildpackage" wrapper of dpkg-cross allows you to compile
> a package with different compilers, without the need to change
> your debian/rules. (usually, some compatibility changes are needed
> to make the debian/rules file "cleaner", but that's all)
> For instance, some programs with lots of calculations (e.g. mplayer)
> are compiled with different processor optimizations (e.g. mplayer-i586).
> Such packages are created by very redundant entries in debian/rules.
> Exactly such redundancy is removed by dpkg-cross.
> Also, these optimized versions get names like "mplayer-i586",
> but their architecture is set to "i386". That means, the *real*
> architecture is encoded in the package name instead of the package's
> This is a work around the inability of apt to automatically use
> the best suited binary packages. (e.g. uses on a i686 system the
> mplayer-i586 instead if mplayer-i386, and the kernel-image-i686)
> If one day apt evolves, packages like mplayer-i586 will step in their
> way. The "Package:" field should not contain architectural information.
> The "Architecture:" field serves that purpose.
> Until APT becomes aware of multiple architectures, this won't change
> much. However, there are still lots of interesting cases where
> more architectures are desirable.
The amd64 project has long ago patched apt for biarch (i386 +
amd64). At the same time people have played around with having
i86 as subarchitectures of i386 as well. The patch to apt (and
dpkg) for this is rather simple and adds the following syntax to
deb http://ftp.debian.org/debian sarge main
deb http://ftp.debian.org/debian sarge(i586) main
deb http://ftp.debian.org/debian sarge(i686) main
If wanted the patches could be freshened up for etch/sid quickly.
> For example, suppose you support a new OS, such as the w32 platform.
> Currently, your only choice is "w32-i386", which means that you must
> use an i486-mingw32msvc Compiler. However, for a w32 system a i486
> compile doesn't make a lot of sense. Since those systems (except very
> old Windows versions) need at least a Pentium, it is reasonable to
> compile such a distribution at least for i586, not i486.
The only sensible choice would be w32, w32-i486 or w32-i586. Nothing
dictates the use of -i386 in a new architecture name.
> That means, the "linux" OS dictates that i386 should mean "at least
> i486", while other OSes (e.g. win32) have different needs (e.g. "at
> least i586"). Such dependencies between the OS and CPU type are simply
> unnecessary and disturbing.
> In that example, there should be a "linux-i386" platform (which may
> be abbreviated to i386), while dpkg-architecture should also allow
> a Debian platform like "w32-i586". This proposal is similar to
> the addition of multiple arm CPU variants to dpkg-architecture.
> Of course, if you want to allow, e.g. the -i386 packaes to be installed
> on a -i586 distribution, some bigger parts of dpkg and apt would have
> to be changed. However, that is not my proposal at all. I don't intend
> to create a w32-i586 Debian distribution which must also accept w32-i386
> packages. I want to create an entire w32-i586 distribution.
> (well, currently, I just want to provide cross compiling packages for
> such a platform)
The biggest challenge would be a good configuration of dpkg for what
subarchs to allow on a system. Patching the architecture check to
allow more archs is rather trivial then. Think about those people that
install their harddisk on a fast Opetron and then put the disk back
into their old i586 system. Having apt/dpkg install i686 packages
there would be bad.
> I also heard about people who compiled a whole (Debian based) system
> for i586 to increase the overall performance of their system. They,
> too, had the same problem: How to name this architecture/cpu? As far
> as I remember, they "solved" that problem by adding a "pentium" line
> (or similar, AFAIR) to their cputable.
> Thus, I don't think it is the question whether one wants to compile
> for i586, i686, etc. There are always good reasons for some groups to
> do so. IMHO, the more important question is how to name that thing. So
> it would be very nice if dpkg-architecture would be flexible enough to
> support that, instead of stepping in the way.
The lack of any larger push for i586/i686 compiled packages and the
reason all previous attempts to include them as archs in Debian have
failed might just be that the gain is so little and only a handfull
packages actualy benefit enough to warant it. And those have their
> To solve the problem at least for cross compiling, there are two
> possible ways to go:
> 1) insert more CPU types into dpkg-architecture
> (e.g. i586)
And tons of debian/rules files. A lot of packages check the
architecture for i386 and do something special then.
> 2) handle an extra CPU list internally by dpkg-cross
> (e.g. when cross compiling for w32-i586, create a package
> like gettext-i586_w32-i386.deb)
Or compile for i386 with gcc overriding the -march/cpu setting and
then change the architecture field to i686 in the deb at the last
> While option 2) is a huge amount of work for dpkg-cross,
> option 1) is relatively easy to do in dpkg.
> In addition, 1) opens the way for apt to support optimized
> binaries natively in the future, and also to use dpkg-cross
> for optimized packages, instead of additional debian/rules
> Optimized and cross compiles packages are not that different, IMHO.
Optimized subarchs and multiarch are very similar and half the
existing patches for apt/dpkg fro biarch/multiarch include them as
bonus as well. I guess multiarch support in apt/dpkg will just slide
them in for free, if they ever get accepted in.