Re: Bug#766708: Processed: Re: Bug#766708: breaks multiarch cross building
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. There clearly is need to simplify gcc
packaging and one way to do that is to remove one of the cross toolchain
build methods.
> Note that the simpler with_deps_on_target_arch_pkgs build is only
> useful where the foreign-arch packages are already built, which makes
> it seem like the 'toolchain-base' method must be used for
> bootstrapping. However Helmut's rebootstrap has demonstrated that the
> with_deps_on_target_arch_pkgs method is useful there too. I must admit
> that I have not fully grokked how this works as I had thought that
> this was the one case where it didn't work.
One can combine with_deps_on_target_arch_pkgs and staged builds. So
while rebootstrap does the same gcc/glibc dance as the toolchain-base
packages, it also uses with_deps_on_target_arch_pkgs to avoid repacking
(because the repacking code is out of archive).
> 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. In the worst case, this
can prevent the main gcc-X.Y packages from migrating to testing, so
clearly gcc maintenance is affected.
This argument only applies to uploading those packages. Thus I believe
it to be irrelevant in the context of this bug.
> Mattias has always said he doesn't want to be responsible for
> maintaining the cross-toolchains, which is fine, I am prepared to do
> that, but that also means he shouldn't get a veto on _how_ they are
> maintained. Obviously if he was maintaining them himself he could
> upload what he likes.
Arguably, the version lock should get him a veto, although he doesn't
seem to have exercised this reasoning in the cross-gcc rc bugs yet (or I
missed it).
> > I am not opposed to disabled with_deps_on_target_arch_pkgs
> > in general,
>
> 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.
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.
I would not have forwarded this issue to the tc if Matthias had not
combined the bad timing with an absence of advance notice.
Helmut
Reply to: