Mailinglist Archive: opensuse-factory (498 mails)

< Previous Next >
[opensuse-factory] Re: New package: newlib
On Thu, 19 May 2016, Andreas Färber wrote:

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.

It's definitely not something I'll do immediately but only in case
it becomes a problem for me when maintaining GCC.

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?

I would make it a branch in devel:gcc but _not_ a branch/link in
Factory (thus have another devel project that is not a branch of
the factor package - gdb is/used to be another).

The advantage is that sources stay in sync but factory sumbission
of the core 'gcc' does not depend on submission of the cross packages.

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.

Of course.

Richard.

--
Richard Biener <rguenther@xxxxxxx>
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB
21284 (AG Nuernberg)
< Previous Next >