[fedora-arm] Agreed linker path changes still not in Fedora

[Peter Robinson]

Hi Steve,

>>> *Every* major distro working on ARM has implemented what was agreed by
>>> all of us in the conf call. Except Fedora. At this point, the message
>>> *seems* to be that Fedora developers just do not care about working
>>> with the rest of the community, and that's a real shame. Please, let's
>>> work together to get this fixed.
>>
>>There is no "except Fedora" here. To quote your own minutes [3]
>>"Fedora; they're planning to do it Real Soon Now." from the meeting,
>>I'm not sure what was said in the meeting regarding releases but this
>>was something I personally didn't want to ship 5 minutes before we put
>>a major release out. That said it will most definitely be in Fedora
>>18, some of it has already landed and the rest will be very soon and
>>quite possibly rolled back into F-17 once its been tested.
>
> There was urgency in the agreement - we all agreed that there should
> *not* be any distro releases of ARM hard-float using the wrong linker
> path. The Ubuntu developers managed to make the minor changes needed
> and QA them in 2 weeks before they released. Fedora are taking *much*
> longer to implement those same changes, which is really frustrating.

So if it was agreed that there should *not* be any distro release
without the changes I don't see such an important decision minuted in
the meeting [1] or discussed in the cross-distro thread. In fact it's
documented that Mentor would be releasing without it and that the
Ubuntu release would have some things correct but not all tools would
be converted.

Fedora 17 has a policy for our secondary architectures that is long
documented [2] for diversion from Primary architectures as well as a
widely known policy for tracking upstream [3] which was discussed very
recently with regards to the issues we've had with mainline kernels on
the cross-distro list. The published schedule [4] for Fedora 17 had
the main feature deadline as 20th March. The thread you started on
this list only stated on 31st March with upstream gcc commits on 26th
April and the upstream glibc commits didn't happen until 8th May [8]
and even on 24th May there was still ongoing discussions.

>>In all likely hood we'll support this in a stable release before both
>>Debian (I couldn't work out their next stable release date from their
>>site) and possible even OpenSUSE depending on if it makes the 12.2
>>release.
>
> *Please* don't release F17/arm without the linker change. The main
> point of the cross-distro standardisation work is to fix the older
> fragmentation problems in the ARM Linux community. Releasing an
> incompatible and broken v7 hard-float distro will set that goal back a
> long way, and cause problems and confusion for users and developers.

Fedora 17 is already released as on May 29th and based on our upstream
policies [2] we're already done, the bits for the ARM side of the
release are to do with minor tweaks and catching up with package
building and technicalities. Anything landing in Fedora 17 will have
to be an update.

I think the thing you're missing here when comparing the Fedora
release to Ububtu 12.04 is that Fedora isn't a long term release the
next release will be in 6 months which is similar time frames to most
of the other hardfp releases. If it's open source being developed on
F-17 ARM it can be recompiled to fix the linker standardisation
problem, and commercial vendors should be well aware of the Fedora
release schedule and it's guarantee of stability especially on what is
currently a secondary arch. Fedora is not RHEL.

Peter

[1] https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
[2] http://fedoraproject.org/wiki/Architectures#Divergence_from_Primary_Architectures
[3] http://fedoraproject.org/wiki/Staying_close_to_upstream_projects
[4] https://fedoraproject.org/wiki/Releases/17/Schedule
[5] http://lists.linaro.org/pipermail/cross-distro/2012-March/000135.html
[6] http://gcc.gnu.org/viewcvs?view=revision&revision=186859
[7] http://gcc.gnu.org/viewcvs?view=revision&revision=187012
[8] http://sourceware.org/ml/libc-ports/2012-05/msg00050.html