Statement on 32-bit i386 packages for Ubuntu 19.10 and 20.04 LTS

I’d like to address a few points from the announcement:

community process to determine which 32-bit packages are needed […] add to that list post-release if we miss something

Sounds like a lot of work, TBH, even if it’s mostly the community (= unpaid volunteers) doing it, lots of hassle. Definitely more than just leaving the i386 buildds running.

use container technology to address the ultimate end of life of 32-bit libraries […] Snaps and LXD enable us both to have complete 32-bit environments, and bundled libraries

Again, why? Why drop something that took years to design & implement, but most importantly already exists and works well – only to replace it with an as yet vague idea of a solution that’s at best over-engineered and at worst does less, less well?
By all means, isolate legacy software as much as is feasible, but I’m not keen on bundling everything and the kitchen sink with applications. I much prefer the traditional way.

There is real risk to anybody who is running a body of software that gets little testing.

How is this a problem for the 32-bit repository but not, say, for 64-bit universe or random PPAs?

The facts are that most 32-bit x86 packages are hardly used at all. That means fewer eyeballs, and more bugs.

One would hope that any bugs don’t hide in the automatically generated packages but in the source code of the software contained therein, source code that is largely shared between other architectures. In my experience, targeting a multitude of architectures makes for better code, as cut corners don’t tend to be very portable.

Software continues to grow in size at the high end, making it very difficult to even build new applications in 32-bit environments.

(New) software that can’t be built in 32-bit isn’t going to require it or be a required dependency, is it? Besides, nobody is asking you to build something that cannot be built. For now, Debian manage just fine, despite having ~10 release architectures, a much larger fully supported repository, and being non-profit.

Don’t get me wrong, it’s your OS, you should be free to take it in any direction you see fit and you shouldn’t even have to explain yourselves. But you did – and as it stands your arguments aren’t very convincing.

2 Likes