I have a suggestion: Wookey, can you use package name like cpp-4.9-armhf instead of cpp-4.9-arm-linux-gnuabihf ? Then we can have both schemes in archive? Wookey, can you remove cross-gcc-* packages from archive temporarily? Doko, can you merge the attached patches? In 0006-gcc-pkg-rename.patch, and when define with_deps_on_target_arch_pkgs, gcc-4.9-ARCH will be generated instead of gcc-4.9-<triplet>. On Fri, Dec 5, 2014 at 11:28 AM, YunQiang Su <wzssyqa@gmail.com> wrote: > On Thu, 04 Dec 2014 20:41:57 +0100 Matthias Klose <doko@debian.org> wrote: >> So in the last email Wookey enumerates a lot of things what he did during the >> last months. Maybe he should have mentioned his ballerina lessons used for his >> performances during the DebConf talks too. However ever all of these have in >> common, that this has nothing to do at all with the work he committed to do. >> >> Further he cites a paragraph from the debian-bootstrap sprint summary, which reads: >> >> """ >> The report from that meeting >> https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results says: >> ---------- >> 3.13. Multiarch cross-toolchains vs single-arch cross-toolchains >> >> This contentious issue was discussed, and is partly covered under other >> headings. Wookey prefers the multiarch builds, Doko prefers the single-arch >> bootstrap builds. We agreed that either provides useful cross-toolchains. It's >> not clear whether it's easier to fix the Ubuntu cross-toolchain-base packages >> to do a bootstrap build in Debian, or to fix the blockers for multiarch builds >> in the archive. Whichever is working first should get uploaded. >> """ > > Good summery, and I also prefer multiarch builds and I also maintain > it for mips64el. > And more: > > multiarch builds can also bootstrap. I bootstrapped mips64el in this way, > and now, it need some dirty hacks,while > if we wish, we can make it much more clean. > > As I noticed that, the argument that to remove multiarch builds > includes (wish I am right): > >> 1. multiarch builds make single-arch some more difficult, and maintain 2 way is not a esay way. > > Yes, while it is more difficult not impossible. > >> 2. multiarch builds needs cross depends, which is hard for Debian infrastructure > > Yes, this is a problem for now, while I think this is the direction we > are stepping for. > >> 3. Bootstrap need single-arch > > No, this is wrong, we can bootstrap Debian with multiarch builds. > The steps are: > 1. cross binutils - we have it in archive. > 2. stage1 gcc, with only C support, and libgcc is also disabled. > 3. stage1 glibc - it is a fake libc6, we can patch glibc to archive it. > 4. linux-libc-dev - we can use stage1 gcc to get it. src:linux > support it now. > 5. stage2 gcc - it has shared and static libraries support now > and libgcc etc are still disabled > 6. stage2 glibc - now we can use stage2 gcc to build glib, and we can get > libc6(-dev) and multilib libc6. > 7. stage3 gcc, now we can build a gcc with C,C++,Go, D and fortran support. > > In every step, we get some DEBs, and we can install some of them, and > go to the next step. > Of course, these steps may make some trouble for packages like > gcc-4.8-armhf-cross. > If we split it to more than one source packages, it is still possible when > infrastructure support. > If you repack these DEBs, it also can archive the goal of current > gcc-4.8-armhf-cross. > > > By the way, if we remove single-arch build, this package will be much > more clean than now, > lots of hacks can be removed from current gcc-4.9 and make life more happy. > >> >> According to >> https://wiki.debian.org/Sprints/2014/BootstrapSprint/Results?action=diff&rev1=30&rev2=31 >> the last sentence was added on Aug 29 during DebConf, long after the sprint >> happened, with a commment "must be almost the final review", without mentioning >> anything. I call this counterfeiting the summary of the sprint. I assume this >> helped to convince other people to sneak in these packages into Debian. What is >> this if not "bad faith"? >> >> Again, the rest of the email talking about willing to work together doesn't >> match the his actions at all. >> >> Matthias >> >> -- YunQiang Su
Attachment:
0001-libgcc-4.9-dev-depends-equal.patch
Description: Binary data
Attachment:
0002-gcc_cross_multiarch.patch
Description: Binary data
Attachment:
0003-allow-no-biarch.patch
Description: Binary data
Attachment:
0004-gxx-crossbase-substvar.patch
Description: Binary data
Attachment:
0005-reverted-removal-of-with_deps_on_target_arch_pkgs-in.patch
Description: Binary data
Attachment:
0006-gcc-pkg-rename.patch
Description: Binary data