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

Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building

+++ Helmut Grohne [2014-11-01 10:38 +0100]:
> On Sat, Nov 01, 2014 at 01:46:48AM +0000, Wookey wrote:
> > To me that sounds like this method is actually the
> > current de-facto default in Debian - it is certainly at least on a par. 
> I don't think that a feature being de-facto default is a good argument
> to force maintaining it forever. 

Well, things being used is a good reason for maintaining them. Nothing
is 'forever'. with_deps_on_target_arch_pkgs is currently just as
well-used as the alternative. I was just trying to get across that's
it's not just some obscure feature no-one cares about.

> There clearly is need to simplify gcc
> packaging and one way to do that is to remove one of the cross toolchain
> build methods.

Is there 'clearly a need'? The gcc packaging is certainly complicated,
and we'd all welcome simplification, but I'm not sure there is
actualyl much scope for that int he real world. A great deal of the
complexity comes from bi-arch and tri-arch multilib stuff, for
example. I'd argue that more use of multiarch would mean we could drop
much of that, at which point the with_deps_on_target_arch_pkgs stuff
is a net (large) simplification. But so far as I know this is not
something the gcc maintainer is at all interested in.

> > There is a set of source packages (uploaded as one per target arch,
> > for manageability reasons, but actually all coming from the same git
> > tree) that builds cross-compilers from gcc-source. These builds
> > currently use the with_deps_on_target_arch_pkgs because a) it works 
> > and b) it's cleaner and simpler.
> Undeniably, the resulting version lock has been brought forward as an
> argument earlier. The cross toolchains resulting from
> with_deps_on_target_arch_pkgs are more fragile than those resulting from
> the default method in the sense that they are subject to the Multi-Arch
> version lock problem. See #766966 as an example. 

Yep. That is clearly the most significant disadvantage of this
packaging. It is an issue in unstable, with frequent gcc uploads but
not in stable and it shouldn't be in testing either. 

Note that in practice as soon as you do any multiarch cross-building
you are subject to the same constraint (via libgcc1) so the practial
difference is relatively small. So someone doing kernel cross-building
in unstable would really notice a difference. Anyone
multiarch-building packages or using testing or stable would not. (I
believe - subject to confirmation by testing).

> In the worst case, this
> can prevent the main gcc-X.Y packages from migrating to testing, so
> clearly gcc maintenance is affected.

How? The cross-toolchains depends on the native toolchain libraries. I
don't see what circumstance would make the cross-toolchains prevent
the main gcc-X.Y packages from migrating
> > I am. It's simple and reliable and (at least IMHO) more correct. There
> > are tradeoffs between the two methods which I'm happy to continue to
> > discuss and work on, but I want it kept around and working (and will
> > help do that) until either consensus is reached amongst the
> > gcc/cross-gcc/rebootstrap maintainers, or we decide that that's simply
> > not possible.
> I think that it is obvious now that "simple", "reliable" or "correct"
> are not universally agreed upon. For this reason, I have avoided them
> and resorted to arguments that assess whether a method is working (now)
> and whether its source is available in the archive.

I have also been clear about stating objective or subjective things.

If you look at the packaging of cross-gcc and cross-toolchain-base it
is obvious that the former is _much_ simpler (5K rules, 12 targets vs
25K rules, 29 targets). Now to be clear, the difference in the gcc
build alone between with_deps_on_target_arch_pkgs
(multiarch-build-deps) and -cross standalone build-deps is
nothing. The difference is in the building of linux-libc-dev (-cross),
libc6-dev(-cross), libgcc1(-cross), libstdc++(-cross) etc. and the
glibc/gcc bootstrap dance. That part is negligible (already done) if the
multiarch-build-deps build is used and complicated if it isn't.

Similarly, after a lot of messing with this it is clear to me that the
simple build is 'reliable' because there is (much) less to go
wrong. I've just spent another couple of hours with the standalone
powerpc-cross-toolchain-base_1.2d Mattias sugested that I use as a
base and have not got it to build on unstable yet. So maybe 'reliable'
is just another way of stating 'simple', but it is an objective measure. 

And I did qualify 'more correct' as 'IMHO', as that clearly is
subjective, I agree.

> If with_deps_on_target_arch_pkgs is going to be used for a long time,
> the code that makes it work likely needs to stay somewhere other than
> src:gcc-X.Y (because it is Matthias' right to not maintain it).  Once
> jessie is released, moving this functionality elsewhere is feasible, so
> I stress that I would not like to see a ruling that forces
> with_deps_on_target_arch_pkgs onto src:gcc-X.Y beyond jessie.

As you say, he is within his rights to take it out, although having
put it in relatively recently, I think that's really a very unhelpful
thing to do. It would be a very painful thing to maintain
separately. We've spent a long time getting to a state where all the
cross machinery is in gcc packaging itself. Taking it out again would
be going backwards.

Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM

Reply to: