Proposal to support uclibc using separate Debian archtypes
[skip straight to the bottom for the proposal sans-rationale :]
On Fri, May 18, 2007 at 05:02:00PM -0400, Eric Cooper wrote:
> You might also want to mine the archives of this list for past
> discussions. Here's a starting point:
>
> http://www.google.com/search?q=site:lists.debian.org+inurl:debian-embedded+uclibc
>
> (and similarly with "cross" instead of "uclibc").
Thanks Eric, I think if anyone doubted that this hasn't already been
discussed to death, and that we've both learned a lot and come a long
way over the last few years, that should quickly put their fears to rest.
The first 90% is clearly done, people have created usable Debian systems
with uclibc, so the time has come I think to tackle the next 90%, and I
think that starts with making some more decisions that work for everyone
and then getting them into 'Debian proper'. I have the luxury of being
able to devote my full time effort into improving this for a while, so
let's make good use of me ;-)
The biggest sore-thumb issue I see at present is the (in)ability to use
an off-the-shelf Debian development system to build target binaries for
uclibc systems. The first thing I'd like to do is get the remaining
changes we need into the core Debian tools for that.
So ...
For the sake of picking a starting point, let's assume the SLIND folk
have got this right, that we do need a separate arch to avoid nasty
conflicts that are intractable to resolve.
How should Debian support that?
Wart says: "add uclibc-arm" to dpkg archtable.
That's a nice simple solution, but I fear it is a little too simple.
Comments in the archtable file indicate that new archs are added there
only when they are added to the distribution. Proposing that uclibc
builds are included in the distro is a much bigger step than just
proposing we support people building them locally. The Moore's law
elves have a bit more work to do with packing and shuffling electrons
before the former is really tractable.
So where should we add this new archtype, (and after that, what should
be its proper nomenclature)?
I don't have much context on the real reasons that archtable contains
only those arches that are actually part of Sid, but I can probably
make up a few of my own to suggest its a good idea.
What we really want is an externally modifiable table that doesn't
require upstream (or source) modifications to dpkg et al. in order to
add a new local build variant which should be kept separate from other
existing archs. Perhaps a directory where other packages can place arch
specifications for use on the local system. Or maybe just an
update-archtable utility that people and packages can use to set the
known archs that may be used on a system.
So I'd like to run a quick straw poll of opinions and reasoned arguments
on just this topic:
- Is there anyone who objects to implementing uclibc support as a
distinct arch type?
- Does a config dir, or a registration tool, sound like the best means
to add 'extended architecture' support to the dpkg* tools, separate
from the list of 'official' archs?
- What else have I missed to support building custom arches from the
base 'workstation' distro?
If we can get something like a consensus, I'll summarise the result in
code to review.
Cheers,
Ron
Reply to: