Bug#774719: missing Build-Depends: gcc-4.9-base
+++ 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
Bug#774719: missing Build-Depends: gcc-4.9-base
clone 774719 -1 reassign -1 src:gcc-cross-support retitle -1 dependencies on cross-gcc-defaults must be versioned thanks On Wed, Jan 07, 2015 at 06:30:41PM +, Wookey wrote: 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. I'll try to be more explicit next time. Thanks for seeking clarification. gcc-4.9-base is not actually essential, it's build-essential, which I presume is what you meant. gcc-4.9-base is actually pseudo-essential in sid as essential packages (transitively) depend on it. 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? You do mean MA:foreign, no? 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. Arguably, it may be useful if these version bumps are done occasionally and on request (i.e. if a major gcc bug is fixed). Having this bumping semi-automatically may help or may not depending on the color of your bike shed. 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. Please don't. We have quite a number of packages that currently Build-Depends: gcc (= ...) (and surprisingly many forget the epoch ;-). Assuming that we will use the gcc-cross-support approach for translating build-depends, this will become Build-Depends: gcc-for-host (= ...). Thus gcc-for-host must use the same versioning as gcc. It can only do so if it can pass on version constraints to cross-gcc-defaults. Note: gcc-cross-support currently gets this wrong. It doesn't have a versioned dep, but needs to do so. Bug added above. 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. We should certainly do something that is close to what the native gcc-defaults does as this works in the native case. Possibly the easiest way to do so is picking the value from gcc rather than gcc-X.Y-base. 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? If it isn't versioned, it'll break lots of Build-Depends (after cross translation). 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. Seems reasonable. Also for cross-gcc-support. 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. What do you think about using the version of the gcc binary package instead? It should update less often and is good enough for the native case. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#774719: missing Build-Depends: gcc-4.9-base
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. Helmut -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
