Re: 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 +0000, 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
Reply to: