Re: additions to dpkg-architecture
Volker Grabsch <vog@notjusthosting.com> 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
> architecture.
>
> 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
i[56]86 as subarchitectures of i386 as well. The patch to apt (and
dpkg) for this is rather simple and adds the following syntax to
sources.list:
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
pkg-i686 specials.
> 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
moment (dpkg-gencontrol).
> 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
> entries.
>
> 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.
MfG
Goswin
Reply to: