Re: 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: helmutg@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/
Reply to: