Volker Grabsch <[EMAIL PROTECTED]> 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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
