+++ Matthias Klose [2014-10-24 14:51 +0200]: > Package: src:cross-gcc-4.9-armhf > Version: 0.6 > Severity: grave > Tags: sid jessie
Using this armhf bug to reply, but the same discussion applies to all of the cross-gcc-4.9-<arch> packages. > This cross compiler is functional incomplete. It doesn't provide the same > frontends that the native compiler provides, and it unusable to cross build > gcc-4.9 itself. > > This package should not enter testing until it is functional equivalent to the > native compiler. This is not a 'grave' bug: that is defined as "makes the package in question unusable or mostly so, or causes data loss, or introduces a security hole allowing access to the accounts of users who use the package." These cross-compiler packages work fine for building most packages in the archive (that have satisfiable cross-dependencies and are cross-buildable at all), or for building upstream software such as kernels. Yes, they are not sufficient to build the gcc packages in the archive (because that needs gccgo and objectivec compilers too), but it would be easy to build those compilers as well, we just started with gcc, and g++ as that's 90% of what most people want and gfortran too as it's simple. Starting relatively small and simple in the archive seemed wise, rather than building every compiler in the collection (and all the gcc-defaults meta-packages that go with them). So you will have to explain why grave is a suitable severity. It seems to me that cross-toolchains which work usefully (we have cross-gcc-4.9-<arch> and cross-gcc-defaults packages to provide the corresponding symlinks) and that combo (along with the cross-binutils packages), should not be prevented from entering testing just because they are not yet complete enough to build gcc itself. There is significant demand for cross-toolchains in stable - we get requests for them often. I think we should try to satisfy that demand, rather than making users wait another 2 years, or have to continue to use 3rd-party repositories. We do not yet have the crossbuild-essential packages which make the toolchains work automatically inside sbuild, because you uploaded those to experimental rather than unstable. I don't know if that can be got into unstable/testing for jessie or not, but it's something that can be dealt with quite simply by changing sbuild config, if not. Where does the requirement that 'cross compilers must be functionally equivalent to native compilers before they can enter testing' come from? My experience is that nearly all users are only interested in gcc and g++, and mostly for arm flavours, but with some demand for other target arches. These toolchains are therefore functional for most people's purposes, even though they don't yet build all the compilers that gcc supports. I think that is a very useful start, and we can make them more complete over time. There will be many packages which don't yet cross-build in Jessie, but mostly due to things that prevent build-deps being installed when crossing (e.g. pkg-config (#759556), perl/multiarch embedded interpreters (717882), flex(761449), and not-coinstallable -dev packages). Having the cross-toolchains (and build-profiles support) available in the normal release makes it easier for people to work on this stuff. So I see no reason to block these packages because they do not include cross-gobjc, cross-gccgo, cross-gcj etc. Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org