[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFC] [Cross Toolchain] Multiarch and sysrooted toolchain

On Fri, 13 Mar 2009 13:54:38 +0100
Simon Richter <sjr@debian.org> wrote:

*sigh* - time to call a halt and face the problems head on.

So, let me spell things out, plain and simple.

> > >, since
> > > they have entirely different objectives
> > Not entirely different - the objective for the packaging tools is
> > actually the same, to have packages install cleanly without changes on
> > systems with a different architecture triplet.
> I'm not sure this can be achieved at all, as we still need a root
> filesystem that isn't prefixed with the architecture triplet.

That isn't acceptable - the current situation is untenable and a
replacement must be found. The only current candidate is multiarch and
what looks like an inevitable handler within dpkg to move certain paths
around where necessary. This handler would later use DpkgClass support
to intelligently handle files within packages that dpkg-cross currently
considers "interesting" whilst dropping other files where there is no
chance of executing them (typically, ordinary binaries).

dpkg-cross has no future, neither does apt-cross. There is no possible
mechanism for retaining the current methodology - it is fundamentally
broken (because it tries to work around standard tools instead of
moving with them) and it has shown that it cannot support the original
aim, to allow sufficient portions of Debian to be cross-built sanely.
I've worked with the code (almost exclusively) for two years now, I
think it should be clear that I have no desire to do so for another
two, let alone another ten. apt-cross, in particular, is
already moribund.

The only reason this is an issue at all is that it has taken 10 years
to get to the point where we finally need to drop dpkg-cross and
therefore we've got used to something that was never truly capable of
being supported for the long term. That is not sufficient reason to
retain it - it is a clear and adequate reason to remove it.

I have no desire to release dpkg-cross or apt-cross with Squeeze. Their
time has come and gone. I'm grateful for what the tools were able to
support during the time that they were useful but *that time has passed*
and both are now holding back development of stable, usable, friendly
and reliable cross-building methods in Debian and Emdebian. Right now,
there is no greater single barrier to Emdebian Crush than apt-cross and
it's reliance on dpkg-cross instead of dpkg.

If we want Emdebian Crush 2.0, we need to drop dpkg-cross. That is the
reality - unless we drop dpkg-cross and apt-cross before the toolchain
freeze for Squeeze, Emdebian Crush 2.0 might not release at all.

We would face exactly the same issues in Squeeze+1 without the
opportunity that currently exists to get our changes into dpkg, making
it hard to see how Crush could recover.

> The other issue is that generally, the 32/64 bit distinction does not
> necessarily mean that we use a different triplet. i386/amd64 does, at least
> in Debian, but that is optional as well and could be changed in the gcc
> package, which would give us a situation where only clearly incompatible
> arches need to be installed into a triplet directory.

If things change, we continue to adapt. Never been a problem for us in
the past.

However, if we ignore the opportunity to get our needs addressed within
the core Debian infrastructure, we only make things harder for the

> > >, and there is generally no need to
> > > install anything but libraries and headers into /usr/<triplet> -- so I
> > > don't think there is a pressing need to replicate a filesystem hierarchy
> > > standard below a triplet directory.
> > True, however, that is not a sufficient reason to not
> > move /usr/<triplet> to /usr/lib/<triplet> and /usr/include/<triplet>
> > if it means getting such support into the core Debian packaging tools.

That is about the size of it, yes.

> Indeed, however this makes building stuff without the packaging tools a lot
> harder 

I disagree - it makes it about as hard as it is already. What's
different is that the mulitarch method is untested and unfamiliar but
that is hardly surprising.

OK, so multiarch may need more changes in the future to make things
easier but multiarch is the only viable option and we cannot afford to
block ourselves into a corner by ignoring it or refusing to make it
work for us.

> -- for example I need to patch gcc to recognize these paths if I
> build gcc by hand. 

Someone had to patch gcc originally to make that support available, the
same needs to happen here. Debian makes lots of changes to gcc for
Debian needs, I really don't see that this can be used as an excuse to
block the original objective - getting cross-building support into the
core Debian packaging tools. The price of that support is multiarch.

> It might be a lot easier to have the packaging tools
> handle the "current" layout than to patch all the software that assumes
> that software is generally installed into "include" and "lib" dirs under a
> common prefix (such as most GNU software that uses the autoconf macros to
> find installed software).
>    Simon

That can't work either. If the core Debian packaging tools are going to
change in our favour at all, they are going to change to support
multiarch - that much has been made clear repeatedly. If cross-building
doesn't get up to speed then the packaging tools could change in a way
that breaks all cross-builds, not just the harder corner cases.
Multiarch isn't perfect for Emdebian but it is the best we are going to
get, it is immeasurably better than what we have (principally because
it can support future development needs) and we need to work with it and
modify it to our needs.

The current layout is simply not an option. It has gone as far as it
can go, it simply cannot cope with forthcoming changes within dpkg or
likely future changes. There is no way to make any progress with
cross-building larger parts of Debian without an unsustainable mess of
multiple layers of package patches, specialised tools and horrible
hacks to what should be standard tools. Perpetuating the current system
will only add back layer upon layer of new hacks, to replace the ones
I've been working to remove, as our methods once again fall behind core
Debian methods and get left to bitrot. If that happens, there will be
no way to expand Emdebian Crush.

A lot of progress has been made in removing old hacks from the current
tools but there is nowhere left to go. The next step is to get support
into dpkg - only then can any of the bugs in apt-cross and the more
complex bugs in Emdebian Crush actually get fixed. That much has been
inevitable from the start.

I think that it is highly unlikely that Emdebian Crush will ever be
able to support more than ARM or armel (i.e. one architecture at a
time) *unless* the current cross-building methods are dropped - the
workload is simply too high. I do not think that is acceptable.

There are problems with using multiarch, yes, but the prize is
infinitely more important than the difficulties. If some things need to
be adapted to work with unchanged core tools then so be it - if some
things still need specialised wrappers, so be it. The aim is and has
always been to get the core cross-building support into the core Debian
packaging tools and that means dpkg and no dpkg-cross, it means apt
and no apt-cross and it means that cross-building needs to adopt and
modify multiarch to the point where we can all use it, albeit with
wrappers and support tools where necessary. Then, we can work on
absorbing those wrappers into the new dpkg when the time comes.

Multiarch is the only deal on the table and we need to make it work,
even if certain features/artefacts of the current system are lost.

Please don't argue the points any further, we may lose all that we have
gained so far.


Neil Williams

Attachment: pgpai3czDwJ8l.pgp
Description: PGP signature

Reply to: