+++ 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. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20141104050835.gb28...@stoneboat.aleph1.co.uk
