Re: additions to dpkg-architecture
On 6/23/06, Volker Grabsch <vog@notjusthosting.com> wrote:
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, ...
Compiling everything for fifteen flavors of x86 doen't make any sense
at all except for it takes fifteen times as more disk space for
package pools.
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.
mplayer is not in debian, so that doesn't make a good example.
Besides, those who compile debs with mplayer do handle the
optimisations just right.
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.
Which seems perfectly fine when 3 out of 18k packages really need
this. But again, mplayer isn't even included in debian.
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.
Having 'CPU variants' is an interesting idea and could use a discussion.
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)
Then why don't you simply patch those {os,cpu}table according to your needs?
I also heard about people who compiled a whole (Debian based) system
for i586 to increase the overall performance of their system. They,
...by 1.5% to 3%, which is undoubtedly great. It's always interesting
how people 'measure' the 'performance of a system', pity it's out of
scope here.
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.
How exactly can it be more flexible?
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)
Ah, so this is all about pushing additional architectures to
{arch,cpu,os}tables? Right, this might be useful. But it's a matter of
preparing a list of architectures and a patch that adds-them-all. You
can't expect dpkg maintainers to start adding random architectures
after this mail. At least we could all have something interesting to
discuss aside packaging mplayer.
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)
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.
Regards,
--
I am free of all prejudices. I hate every one equally.
Reply to: