Proposals of deprecation/removal, mainly affecting toolchain
Get series with b4
b4 am [email protected]Versions newest first
- v1 Latest0 of 10 patches 0 repliesNew
Patches in v1 No applies recorded yet
None of the 10 patches the cover letter announces are in this archive.
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [Buildroot] [PATCH 00/10] Proposals of deprecation/removal, mainly affecting toolchain
Dear Gustavo Zacarias,
Quoted 3 lines · Gustavo Zacarias
Quoted 1 line
- Deprecation of the AVR32 architecture.
+1 from me, it's a dead-end and i've been (not secretly) hoping for this.
Right, me too :)
Quoted 7 lines
Quoted 5 lines
- Removal of old binutils versions
- Removal of uClibc 0.9.32.1
- Removal of gcc 4.3.x and 4.6.x
- Removal of gdb 7.4 and 7.5
- Removal of busybox version selectionAll of these should follow the deprecation guidelines i think?
Does it really needs to follow a deprecation process, when those versions are no longer the default versions for any architecture since a long time, and there are alternatives offered by simply switching to a newer version. In my opinion, a deprecation process is needed when we intend to really remove a feature (such as AVR32 support, or a complete package), but not necessarily when removing really old versions of toolchain components, not used as the default version since a long time.
But I'm open to others opinions on the matter, and will re-adjust the patch series accordingly.
Quoted 4 lines
Busybox in particular should keep at least a previous version around, because there have been cases of .0 releases being quite broken. Maybe patches show up soon but they don't follow a release schedule like we do and there could be problems with that.
We don't keep two versions of any other package, why would we do it for Busybox that is widely tested, and therefore most likely issues are going to be found before we do a Buildroot release?
If people insist, I'm OK with keeping a version selection, but I find it pretty useless to have it specifically for Busybox and not for all the other packages that we have. For example, when bumping Qt from 5.3.1 to 5.4.0, should we keep 5.3.1 around because 5.4.0 is not guaranteed to be as stable?
Quoted 3 lines
Also punching a hole in gcc version continuity even though logical sounds dirty (and really they aren't stopping any features other than missing atomics in old versions).
Yes, I know the hole is a bit weird, but 4.3.x and 4.6.x are the only versions that can be easily removed: 4.4.x is still needed for SPARC Leon (hence the mail I've sent to Konrad) and 4.5.x is still the default version for Blackfin (would we be able to bump this? I remember you did the internal toolchain support for Blackfin). Basically, I'd like to get rid of 4.2.x (by removing AVR32), 4.3.x (can be done now), 4.4.x (by updating the Leon support), 4.5.x (by updating the Blackfin support) and 4.6.x (can be done now), and therefore keep only 4.7.x, 4.8.x and 4.9.x.
Thanks for your feedback!
Thomas
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com