Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
On Sat, Nov 22, 2014 at 08:51:41PM +0000, Dimitri John Ledkov wrote:
> On 22 November 2014 at 16:21, Ron <ron@debian.org> wrote:
> >
> > Dimitri wrote:
> >> Thus multiarch cross tooling is not so relevant for fresh bootstraps,
> >> and/or targeting non-debian architectures, or otherwise incomplete
> >> systems (e.g. those that do not have compatible set of pre-compiled
> >> binaries that use multiarch-paths
> >
> > I'll leave it to Helmut to talk about his existing work with bootstraps
> > that's been stalled by reverting this patch.
> >
> > I can categorically say though that we are currently using a toolchain
> > built this way on Jessie before it was broken by this change, both for
> > embedded systems that do run Debian, and for microcontrollers that
> > couldn't possibly run it (memory measured in kB, no MMU). It works
> > just fine for all of those cases.
> >
> > The *only* problem we have at present is that we can no longer update
> > the Jessie systems this was being done on, because our ability to do
> > this was removed and there appears to be no actually working replacement
> > for it.
> Also since it is a source package change, rebuild outside the archive,
> one is free to patch it, thankfully the source packaging is open
> source which one can patch when rebuilding toolchains in the partially
> new to jessie ways.
So ... you're saying that ... if someone manually restores this
for themselves, they can have back the only behaviour that has been
tested and is known to work (well or at all) for Jessie with m-a,
but if it is restored in advance, so our users don't have to do that
manually ... then the universe somehow comes to a cataclysmic end?
Can you point us to the actual explanation of what *breaks*?
The people who have actually been working on this _in Debian_ are
well aware of what is not perfect about it and what extra work
remains for post-Jessie to make it more so, and they are actually
working on those things.
They even have packages based on this uploaded to sid, so that the
other work on fixing those things can continue, e.g.:
https://packages.debian.org/sid/gcc-4.9-arm-linux-gnueabi
What nobody has explained to us is what problem is *fixed* by
gratuitously breaking this for existing users of Jessie.
> >> Can we all settle and move these developments to experimental
> >> targeting for stretch, instead?
> >
> > Nobody is suggesting that other options can't be, or shouldn't be,
> > explored for post-Jessie. Restoring the functionality that existed
> > before this was removed will not in any way prevent or hinder that,
> > it just means we won't repeat the sad state of Wheezy where this
> > became no longer possible at all.
> >
> > Nothing you said here explains why we can't have the best of both
> > worlds with this. If having this working for Jessie is "not so
> > relevant" to you, that's fine - but it's very relevant to quite a
> > few other people and was working for them until a few weeks ago
> > when support for it was simply removed.
> >
> > We have people prepared to do the work to keep it working.
> > What we don't have is an explanation of what it actually broke,
> > if anything, to warrant removing it, without comment or warning,
> > at this late stage of the Jessie release.
> This bug report annoys me a lot, given the amount of inaccuracies it
> has in portraying the current state of the affairs - that is
> exaggerating the regression, when simply a desired feature by some,
> failed pear-review was found feature incomplete and was not fully
> included into jessie.
You haven't actually pointed out anything inaccurate that anyone has
said here, and having this working is actually a pre-requisite for
some of the other work that you're saying isn't yet done, to be done.
Yes, it's still a bit more awkward to build a toolchain than we all
would like, but this is still infinitely easier and cleaner than
anything we've ever had before. What do we gain by denying people
the ability to easily use and experiment with that, in real life
use cases, while we work on improving the other things too?
Can you point us to this "pear-review" that you say occurred?
The only thing I can see is that this functionality was quietly
removed on the eve of the freeze, without any discussion with the
people working on this _in Debian_, and that trying to discuss that
is what led to this going pear-shaped and needing to be escalated
to the -ctte for mediation.
> Given a zero sum game rules,
Fortunately, this isn't a zero sum game. We can have the Good now
without ruining anyone's chances of making that Perfect later.
Why is it in the interest of Debian or the users of Jessie to not
(continue to) have that?
Ron
Reply to: