Re: additions to dpkg-architecture
On Sun, Jun 25, 2006 at 10:27:37PM +1000, Brendan O'Dea wrote:
> On Fri, Jun 23, 2006 at 06:54:49PM +0200, Volker Grabsch 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, ...
> [...]
> >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.
>
> While there are certainly some packages which may benefit from
> compilation with sub-architecture optimisations, those packages are the
> exception rather than the norm.
This is a good reason for Debian not to supply more optimized packages,
but this has nothing to do with my proposal.
> It may make sense to provide multiple versions of the kernel for
> example, and perhaps glibc... but coreutils? grep?
I don't understand what you try to explain here. I didn't propose
the Debian should provide multiple optimized versions of more
packages.
Please don't mix the DPKG tools with the Debian distribution. For the
same reason APT facilitates inofficial repositories, dpkg should
facilitate their creation.
> Do you propose re-building all packages for each sub-arch?
No, that's not my task, and it also shouldn't be the task of the
Debian project. I just want the "dpkg" tools to open the way for
those who want to do that, instead of stepping in their way.
If "dpkg" had some more architectures in the past, I'm sure we'd
have more optimized (inofficial) APT repositories in the net.
> If so, [...]
> If only a sub-set, [...]
I don't want Debian to re-build any of their packages for those
new sub-archs. I just want Debian, more precisely: DPKG, to supply
a naming scheme where everyone finds a place: The officially supported
Debian architectures as well as those which are only interesting for
a minority.
Because adding architectures to dpkg will be done by those who need
it, and because it's very easy, I don't think there's any problem
with the cost vs. benefit. The cost are minimal, and there's a
reasonably big minority who will greatly benefit. IMHO, it is just
a question of courtesy: Not to step others in their way.
I'm sure the Debian-embedded and other cross compiling folks are glad
to maintain such a scheme, as they are the ones who usually work with
many architectures and thus have the motivation and the necessary
background knowledge. This is at least my impression of them.
> how are you intending to change dpkg, apt and/or the
> archive software to handle opportunistic installation of sub-arch
> packages with fallback (i.e. try foo.i686, fallback to foo.i386)?
I don't intend to change dpkg in this way, I just thought this would
be a very dersirable feature for the future. As I stated in my proposal
with various examples, the addition of more architectures would have
big benefits anyway.
However, if one day the kludge with optimized packages etc. should be
solved cleanly, I would like to have it in that way:
The APT configuration contains an architecture priority list, such as:
i686,i585,i486,i386
The first entry is the best suited, the last one the least suited.
When doing APT-update, APT knows what packages are avaiable in what
architectures. It then simply takes the one which is the best suited
one according to the list.
To make it more user friendly, there should be prepared lists for
each architecture, e.g.:
i386 -> i386
i486 -> i486,i386
i586 -> i586,i486,i386
i686 -> i686,i586,i486,i386
Thus, the user just has to choose his own architecture and the rest
is taken from the tables.
While this approach is AFAICS the most flexible one, probably a simpler
structure solves the needs, too. Instead of having a list for each
platform, maybe it's suitable to just store the predecessor, e.g.:
i386 ->
i486 -> i386
i586 -> i486
i686 -> i586
In all cases, this structure should be only used to determine a default,
so the user has the last word about his list of architectures. Maybe
he want's to cut the list to e.g. "i686,i586" to guarantee a minimum
optimization level for all packages. Or maybe his hardware is not fully
backwards compatible, e.g. his i686 processor has problems with i486
optimized code, so he would use "i686,i585,i386". Okay, my examples are
not that good. I just wanted to state that the user should still have
the last word for the architecture priority list.
Does this answer your question? I'm not sure I got you right, because
all I wrote here seems obvious to me.
Greets,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Reply to: