Mailinglist Archive: opensuse-factory (498 mails)

< Previous Next >
[opensuse-factory] Re: New package: newlib
Am 19.05.2016 um 13:12 schrieb Richard Biener:
On Sat, 14 May 2016, Andreas Färber wrote:


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 - 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.


In devel:gcc that could be a branch of the gcc package but in factory
it would be two different packages.




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@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups