+++ Helmut Grohne [2015-01-06 20:19 +0100]: > Package: src:cross-gcc-defaults > Version: 0.4 > User: helm...@debian.org > Usertags: rebootstrap > > While gcc-4.9-base is essential in unstable and jessie, it is > unavailable in wheezy. Therefore it would be good to mark > cross-gcc-defaults as not being buildable there by Build-Depending on > gcc-4.9-base.
Hmm. I'm not sure about this. This package could be built for wheezy if you wanted to (although it's not available there) and it's probably even useful with the emdebian toolchains, so I don't see why we should do anything to explicitily disable this. But I see that the actual point here (which you didn't make clear above) is that currently it fails if gcc-4.9-base is not installed because it uses it to derive the current version number of gcc. gcc-4.9-base is not actually essential, it's build-essential, which I presume is what you meant. I'm not convinced that we should add a build-dep on a build-essential thing, just to make sure that it will fail marginally faster on a suite for which it is not available. The best reason for listing such build-deps is to help bootstrapping, and this one is MA:same, so maybe that makes sense? Considering in a bit more detail how this should really work: Currently cross-gcc-defaults sets package-triplet version to build time gccbase ver and sets its Depends: package-ver-triplet (>= build time gccbase ver) Thats only useful if a new cross-gcc-defaults is uploaded (or a binnmu requested) everytime a new cross-gcc-<ver>-<arch> is uploaded (and this does mean that the version number match up for users so they don't get confused what version of the compiler is installed). But gcc-native is not doing this: apt-cache show g++ 4:4.9.2-1 apt-cache show g++-4.9 4.9.2-10 And neither are we currently. It would probably be easy to arrange to binnmu this for every new cross-toolchain upload and make sure they _do_ match up. If the versioned-cross-compiler and cross-compiler package version numbers don't match up then maybe the unversionned (gcc-<triplet>) packages should just use the source version, and stop pretending to match. If we did that then the build-dep on gcc-x.y-base would go away. Similarly the Depends: >= 'build time gcc base ver' isn't useful so far as I can see. It should either be a fixed value that changes when there is some actual change in the package sets provided - e.g. front-ends added/removed, or architectures added/removed. (I think this is what the native gcc-defaults package is doing.) But of course that does require someone to remember to update it. Or there shouldn't be a versionned dep at all. After all this is just a link. Any available, installable, cross-toolchain package will satisfy and work, so I'm not convinced that we need anything more explicit. Can anyone come up with reasons why that won't work? This packaging also doesn't cope with architecture version skew. The current multiarch builds make that essentially impossible anyway so that's fine. But if we started depending on -cross libc packages than there could be skew that the default package should (?) take into account. The longer-term plan is (was?) for this package to merge into the main gcc-defaults so maybe it's not worth worrying about much. So, for now I propose not to add the build-dep, and not to change the version-number logic, and try the binNMU-on-upload idea. If that's not a faff then I think it'll be nicest for users. I will (at some point) either remove the versioned depends, or make that version a genuine 'minimum version this works with', and only changed when there is an actual change. Comments welcome. Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org