John Paul Adrian Glaubitz <glaub...@debian.org> added the comment:
> What is the use case or benefit of building Python for 32-bit rather than > 64-bit? That's not really the question. The question is whether an upstream project should prevent downstreams from using unsupported target configurations and I think the answer to that question is no. Python is free software (as opposed to just open source software) and one of the key features of free software is that you don't tell your users how they use your software. Open source licenses that limit use cases of software are considered non-free by most if not all Linux distributions for that very reason. There are valid reasons for preventing your software from being built on certain targets - such as the maintenance burden for architecture-specific code - but none of them apply here. A few lines of autoconf plus some preprocessor macros don't pose any burden and therefore the choice should be in favor of allowing downstreams to build unsupported configurations. As for providing a CI: Setting up a CI machine for individual upstream projects is not a problem for big corporations like IBM or Intel, but it is certainly a hassle for individual open source developers and hobbyists. And while we (Debian Ports) have provided some CI machines for individual upstream projects such as GCC and LLVM, it should be sufficient for most upstream projects to rely on Debian's buildd infrastructure as we simply don't have the resources that big corporations have. As for your original question: We still maintain multiple 32-bit ports in Debian, both as official and unofficial releases, and the same is done in other Linux distributions such as Gentoo, openSUSE, Void and others. Lots of hobbyists are pouring a lot of lifeblood and efforts into these ports such as m68k - which has still a surprisingly large user base thanks to retro-computing fans - which is why I am kindly asking you to not put up any obstacles into our ways. As I said before, the Python interpreter is one of these excellent works of engineering that just work. Other interpreters/compilers such as OpenJDK, Ruby, Go or Rust require much more attention to keep them portable while the Python interpreter has never caused any issues which is something I am very grateful for, in particular given the fact how much other code directly depends on the Python interpreter to work (just think of the many package managers and other system tools written in Python). So I think I can speak for Debian, Gentoo and many other downstream projects that it is important for many that it stays that way. Of course, that shouldn't Python development keep from moving forward and if the dependence on architecture-dependent code should increase at some point, we can still discuss this issue again and we will be more than happy to help with the porting efforts. Thank You! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue43179> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
