Hi Marcin, Thanks for whipping these packages into shape!
On Thu, Sep 16, 2010 at 06:19:28PM +0200, Marcin Juszkiewicz wrote: > 1. a-c-t-base is at 1.47 in archive and was built from gcc-4.5-source > 4.5.1-6ubuntu1 version. This package is used to bootstrap armel cross > toolchain and generates: > - binutils-arm-linux-gnueabi (from binutils-source) > - libc6(-dev,-dbg)-armel-cross (from eglibc-source) > - linux-libc-dev-armel-cross (from linux-source-2.6.35) > - gcc-4.5-arm-linux-gnueabi-base, libgcc1(-dbg)-armel-cross (from > gcc-4.5-source) > libgcc1* packages have /usr/share/doc/ directories as symlinks to > /usr/share/doc/gcc-4.5-arm-linux-gnueabi-base/ > I have a version which does not provide gcc-4.5-arm-linux-gnueabi-base > package, libgcc(-dbg)-armel-cross depends on gcc-4.5-base and have > /usr/share/doc/ directories pointing into gcc-4.5-base one. Need to fix > this symlink by providing those files in libgcc1 package instead. I'm not really in favor of pointing at gcc-4.5-base, because I think ultimately we want the version number of the binary packages to be able to tell us at a glance what version of a-c-t-b they came from, and we want the changelogs to give information about changes to the a-c-t-b packaging and not just information about the gcc-4.5 source package. Dropping gcc-4.5-arm-linux-gnueabi-base and symlinking to gcc-4.5-base instead moves us away from that goal because it leaves us with no place to ship the a-c-t-b changelog. This isn't a blocker, and if we're doing multiarch next cycle it should go away because we don't need libgcc1-cross any more; this is just my soft impression. But ideally, yes, these files would be shipped in the libgcc1-armel-cross package instead of pointing at gcc-4.5-base. > 2. gcc-4.4-armel-cross is at 1.36 in archive and was built with > gcc-4.4-source 4.4.4-14ubuntu4 version. This package provides > compilers, libstc++6-4.4-(dev,dbg,pic)-armel-cross, > libmudflap0-4.4-dev-armel-cross and gcc-4.4-arm-linux-gnueabi-base > packages. > I have 1.38 version ready to upload which fixes #637454 #640298 bugs. Bug #637454 is a low-priority bug which currently only has the affect on armel of pulling in redundant build-dependencies. We would be fine to not fix that in maverick - but if you have the fix available, I'm also happy to review that. Bug #640298 is a fix that we pretty obviously need in for these packages to be useful in maverick. In cases such as this, please upload directly to the freeze queue! There's no need for review by email for such a straightforward and high-priority bugfix. > 3. gcc-4.5-armel-cross is at 1.35 in archive and was built with > gcc-4.5-source 4.5.1-7ubuntu1 version. This package provides compilers > and runtime libraries. But it does not provide > libgcc1(-dbg)-armel-cross and gcc-4.5-arm-linux-gnueabi-base because > they are in a-c-t-base source package. All resulting packages have > /usr/share/doc/ directories pointing into > gcc-4.5-arm-linux-gnueabi-base one which is policy violation. > I have 1.37 version ready to upload which fixes #637454 #640298 bugs and > provides gcc-4.5-arm-linux-gnueabi-base package so policy violation is > removed. But you're only moving the policy violation from one package to the other: you say that the binary packages from a-c-t-b will have to point across source packages to gcc-4.5-base, which is the same policy violation in a different package. So I think that part is needless churn and should be reverted - please keep the same binary packages built from the same source packages as they are currently, just get the rebuilds done that are needed to ensure installability. > 4. gcc-defaults-armel-cross is at 1.3 in archive and does not require any > changes. > Main problem is that packages generated from gcc-4.5-source are split into > two packages: armel-cross-toolchain-base (libgcc1(-dbg)-armel-cross) and > gcc-4.5-armel-cross (all the rest). This was required to allow to > bootstrap cross compiler but gives problems when one is built with other > version of gcc-4.5-source then other - resulting packages are not > installable (we have it now in archive). It is also a thing which > Matthias does not like and I understand it. For now my only solution is > to build both with one version of gcc-4.5-source. Well, I think this is a red herring anyway. Pointing at gcc-4.5-base should *also* mean uninstallability when you have out-of-sync versions, because we should be pointing at the matching version to ensure the correct changelog; and more importantly, we need to have all of these packages built from the matching version of gcc-4.5-source at release time, to ensure we're complying with GPL provisions regarding source code availability. Having out-of-sync packages turn up as uninstallability problems every time is inconvenient for the user trying to track the devel release, but it's also a very pointed reminder to rebuild the packages - a reminder that we won't accidentally overlook. I appreciate that Matthias may not like the frequent uninstallability of these packages, but license compatibility is a higher concern. And besides, while I am grateful for Matthias's help sponsoring these cross-compiler packages into the archive, it's not his responsibility to maintain them, it's ours - so if we have to step up our game to keep the packages usable in the face of gcc uploads because Matthias isn't going to take on this extra load, then that's what we'll do. :) Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
_______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
