Re: new architecture wishlist
On Tue, Jun 30, 2009 at 03:29:08PM +0200, Simon Richter wrote:
> a few days ago I asked on #debian-dpkg whether it was possible to get a
> mechanism for adding new architectures to dpkg by dropping extra tables
> into a specific directory.
I've cc'd #455501 on this, as that is still an open thread on what to
do about the linux uclibc targets, and the last suggestion there was for:
uclibceabi-linux linux-uclibceabi linux[^-]*-uclibceabi
uclibc-linux linux-uclibc linux[^-]*-uclibc
uclibceabi-linux-arm uclibc-linux-armel
uclibc-linux-<cpu> uclibc-linux-<cpu>
I'd like to suggest that the form in triplettable should instead be:
uclibceabi-linux-arm uclibc-armel
uclibc-linux-<cpu> uclibc-<cpu>
As this is consistent with other arches there in that we assume 'linux'
by default, and only add the extra qualification for non-linux kernels.
I've been building uclibc toolchains and using them for active development
for more than two years now, originally with the old ABI and most recently
with gcc-4.4 and EABI, and this has been working well ...
But that said, I now _don't_ think we should add these to dpkg by default,
if anything we should _only_ more formally define the form that should be
used. But more on that in a moment.
> Given that these tables are ordered by regex specificity and that there
> ought to be at least some arbitration in the architecture namespace, it
> appeared to be the best solution to simply add new architectures in the
> dpkg package, whether they are official Debian architectures or not.
Hmm, ok, that is indeed something of a problem for just dropping extra
definitions in a foo.d for dpkg to read (which I'd also lobbied for
previously). But we _do_ already have DPKG_DATADIR now, and I have
used that successfully with the most recent toolchain I built.
There are a few issues with it, but none that seem insurmountable.
What other problems are other people having with that which make it
an unacceptable solution at present? The basic concept seems sound,
the only troubles I've seen are the usual issues that environment vars
all have.
What if we allow just a single set of foo-table.local files on each
machine? That if present will override the packaged tables from dpkg,
but will not be overwritten each time dpkg is updated. If people want
multiple additional arches it will be up to the local admin to merge
them into the *.local files provided for that use (along with any from
the official set they require) ...
> So I'd like to collect a wishlist here and ask for comments:
>
> Debian GNU arch GNU regex
> -----------------------------------------------------------------------
> armebuc armeb-uclinux-uclibceabi arm.*b-uclinux[^-]*-[^-]*eabi
> armeluc arm-uclinux-uclibceabi arm-uclinux[^-]*-[^-]*eabi
I'm against defining these two for the same reason I'm against defining
the linux-uclibc ones above. The _only_ reason for using these builds
is you are really tight on space, which pretty much guarantees that
_every_ actually useful build will be incompatible with every other (as
there are gazillions of configuration options to include or exclude
various things).
Making some 'official' definition of what these consist of just doesn't
seem practical -- either they will include _everything_, which aside from
being impossible for things like MMU support, will simply make them too
bloated and so useless for _everyone_ -- or they will be defined to suit
the first player and everyone else will be left out in the cold.
Either we should leave these as 'user defined' arches, that people can
define locally as they please -- or probably better, use these as a
standard form, that people can then customise to make their own custom
uclibc_foo-armel arch. That _should_ work, but I haven't actually made
a toolchain like that to prove it. A few autoconf globs may need to be
tweaked in some things, but by eye most seem to have wildcards in the
right places for this to work. Mostly I'm just not certain they all
agree on _where_ in the name we have freedom to add things like that,
but that doesn't seem unfixable (or undesirable to fix) either.
> win32 i586-mingw32msvc i(3,4,5,6)86-mingw32msvc
> win64 (to be decided by mingw maintainers)
> cygwin32 i686-cygwin i(3,4,5,6)86-cygwin
I'm against adding these because after some 8+ years of maintaining
the mingw toolchain (since gcc 2.95), they are still utter vapourware,
don't really fit with being a distro arch in any sensible way (there
is nowhere you can install the 'native' packages), and aren't required
at all for creating a mingw-cross development environment hosted on
Debian systems. People have been cross building for this target for
many years now, and every effort that has started with defining what
to call the arch has amounted to absolutely nothing at all. In the
meantime, plenty of people and projects seem to be getting their work
done with this toolchain just fine. We even dropped some of the above
'arches' from dpkg-cross a couple of years ago when that was merged
with dpkg, and I have no link to offer re any real complaints about
that which I'm aware of to date.
I think the double handling of building 'native' packages that will
never be used and then dpkg-cross'ing them is an 'obvious' reuse of
existing cross build methods, but one that fits badly to an arch that
doesn't follow the norms of a Debian system at all. If people really
want to do this, then IMO they should prove this first with local use
of DPKG_DATADIR for now. It would be a mistake to complicate the
dpkg-cross mechanisms to cope with this, and vice-versa. And however
seductive this may look as an 'easy' first step, you aren't going to
have to go too much further than that to hit nasty trouble.
If we're going somehow support 'debs' of non-debian arches, we really
need to answer the "how are they different" and "where are we going
to put them" questions much more thoroughly before we concrete parts
of that into dpkg.
Anyhow, I'd been meaning to follow up to #455501 for a while now with
a report on how all that was all looking, so this was a pretty good
cue to get a coredump from me on that. I think the next step I'd like
to see here now is some broader discussion on the known failings of
DPKG_DATADIR, and a few more people thinking about the best ways to
address that.
Being able to locally define an arch is _very_ useful for embedded
developers -- but enumerating every arch they define before we even get
a chance to see if they make it out of the R&D lab seems intractable
and wasteful of a still rather limited namespace. dpkg should probably
stick to just defining arches that debian distributes, but provide us
enough knobs to tweak for new arches to be easily bootstrapped, some of
which may later become part of the project archives too.
There may be other arches that we do want to add to dpkg already, but
my feeling on this particular lot is that pretty much all of them will
come back to bite us later if we hardcode this in the distro dpkg now.
Thanks for giving us some time to have another look at what to do about
all this though ... It would be really nice to bed down a few more of
the things that we are actually pretty sure about now ...
Cheers,
Ron
Reply to: