Am 19.05.2016 um 13:12 schrieb Richard Biener:
On Sat, 14 May 2016, Andreas Färber wrote:
Hello,
Newlib [1] is a C standard library (i.e., alternative to glibc). [...] newlib serves as source package that further cross-*-newlib-devel.spec files can be generated in and _link'ed (similar to dtb-source package).
The gcc5 and gcc6 packages [7, 8] are already prepared for newlib.
The spec files used for testing specific cross-compilers have been dropped from newlib for now, as there is a two-step dependency between gccX and newlib, avoiding unresolvable build requirements in staging.
My suggestion is to merge this newlib stub package first. We can then branch newlib to devel:gcc, prepare gcc5 and/or gcc6 cross packages there and then submit gccX and newlib packages alongside through one staging project.
Alternatively we could first submit cross-*-gccX-bootstrap packages that don't depend on cross-*-newlib-devel packages yet, but they would be of little use on their own and should rather not get published (similar to systemd-mini package).
An oSC16 lightning talk [9] is planned with an update on this topic.
First of all thanks for continuing to work on this.
I have an issue with putting additional crosses into devel:gcc via the gcc5 or gcc6 source packages. Factory submissions require that all .spec files linking to the main package build which is quite a burden already with some of the "stupid" crosses we have. Adding in newlib crosses both increases build time and introduces new failure paths I would have to deal with.
This is probably a more general issue of multiple .spec files refering to the same source. I don't like the idea of splitting the source itself too much but eventually I will start doing this if things become too uncomfortable. That is, have a cross-gcc-source "stub" package aggregating all the cross spec files.
I don't mind you splitting your package, but FTR let me say that in the ~year that I've been building these cross packages I've never had a build failure that was not due to the tarball file name changing (and thus resolved by re-running my branched pre_checkin.sh - an issue we wouldn't have in devel:gcc) or a general build breakage of gcc5. I.e., zero failures due to newlib so far. Of course that's not a guarantee for the future. I agree this shouldn't hold up native compiler updates unnecessarily. On the other hand though any major gcc updates (gcc5, gcc6) go through long-term staging projects that would probably allow fixing any cross-compilation issues alongside. And if there's a breakage you could still comment out the broken targets in change_spec until someone fixes them. More specifically if we add cross-compilers to gcc5 today then gcc6 doesn't have them unless someone makes an SR to gcc6, which should require to have successfully built it first. My main concern is that I would like to base our cross-compilers on a current and maintained gccX package, whether directly or indirectly. We already have separately packaged cross-compilers bit-rotting in CrossToolchain:sh4 and CrossToolchain:mingw:test and really don't need the same thing in devel:gcc. So if a branched cross-gcc5-source package breaks due to a gcc5 package update, aren't the effects the same as if we do it from gcc5 like today? Or would you want to keep cross-gcc-source completely separate (no _link) from gcc5/gcc6? Who would update it in that case and when? Also for clarity, IMO non-upstream targets such as pru would need to stay in a separate project, to not break updating - similar to how our kernel packages don't contain random downstream patchsets. Regards, Andreas
In devel:gcc that could be a branch of the gcc package but in factory it would be two different packages.
Thanks, Richard.
Regards, Andreas
[1] https://build.opensuse.org/request/show/395228 [2] https://build.opensuse.org/project/show/home:a_faerber:epiphany [3] https://build.opensuse.org/project/show/home:a_faerber:rx [4] https://build.opensuse.org/project/show/home:a_faerber:rl78 [5] https://build.opensuse.org/project/show/home:a_faerber:pru [6] https://build.opensuse.org/project/show/home:a_faerber:uclinux [7] https://build.opensuse.org/package/show/devel:gcc/gcc5 [8] https://build.opensuse.org/package/show/devel:gcc/gcc6 [9] https://events.opensuse.org/conference/oSC16/program/proposal/918
-- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org