On 2022-09-28 11:09 +0900, Dominique MARTINET wrote: > > As far as I'm aware, there haven't been any new public discussion since > that 2020 thread
I mentioned it in the 'arm status' talk at debconf this year. -- has there been any new attempt I missed? I have been planning for a while to have a go at a bootstrap but have not actually done anything yet. It is rising up my list as 'most important task' (currently after 'fixing porterbox abel'). > I won't bring anything very useful to the table here: I'd be happy to > give some limited time, I'm glad to hear that there is some interest from others. > My naive opinion is that having a flag day and dealing with fallouts > might ultimately be the fastest way forward, but as there won't be any > safety check to detect incompatibility I don't think anyone will be > looking forward to the weird errors that will ensure for e.g. locally > compiled programs and whatsnot. We don't have a mechanism for a flag day SFAIK. We can't suddenly re-upload every package in the armhf archive. And people would still download new 64bit time_t packages into their existing armhf installations and (presumably) have everything break. It's a new ABI - we have to assume the breakage would be pretty bad. It would be nice to do it within the armhf archive but although we have mechanisms for core library transitions (like we did for libc5 to 6) a) this affects all arches so is a lot of churn for an issue only affecting one arch (or maybe all 32-bit arches, but I'm not sure how many of those other than arm (v7) will be around much longer? Given the nature of this change I'm not even sure this would work if we were up for the work, and I don't think we collectively are. > So that might be the first thing to think about again? A new debian arm ABI arch is definitely the easiest way to do this, as Arndt says. Having thought about it a bit, I suggest we just call it 'arm32' as in the future it will be useful to distinguish legacy 32-bit arm from arm64 (and maybe armv9 or whatever variants come in the future). And having just 'arm32' and 'arm64' arches will be quite pleasing for however long it lasts. Obviously bikeshedding about the name and triplet is the least important part of this. Andt Bergman wrote: > Last time, the discussion got stuck because that means introducing a > new target name for dpkg, which then requires a new target triplet > to allow a multiarch installation. This in turn requires additional > work for porting packages that need to know about the new target > triplet. I don't think we can solve this problem now, but should > postpone the inevitable debate about this until someone has done the > work of rebootstrapping a working armhf environment with the current > names. Agreed. And this was my plan. Just so we can check that stuff basically works before patching toolchain builds. Given that arch have it working it should be (?) as simple as setting some flags and doing a rebuild (and fixing whatever breaks). Wookey -- Principal hats: Debian, Wookware, ARM http://wookware.org/
signature.asc
Description: PGP signature
