Closed olof-nord closed 2 years ago
I would like to ask why do you think this would be a good idea and how would it be benefitical to the project? This would more than likely introduce tech debt that we may not want.
Very valid question.
I own a riscv system myself. With this, I would like to run Seafile. Seafile provides their own docker images with the seafile-docker project.
The Dockerfiles used by seafile-docker all depends on this project for their base image. I my quest to run Seafile on riscv hardware this project comes first in the list of enabling the riscv platform for the project.
What technical debt do you anticipate?
I notice that the ARM and ARM64 platforms are supported. How come they are supported, what if any process was in place when choosing to support them?
With the QEMU and docker buildx CI setup, I got the impression that the project was open for other architectures.
What technical debt do you anticipate?
What happens when Ubuntu decides to drop that support? What happens when we get bugs related to it, that we cannot ourselfs troubleshoot because we do not have that architecture hardware? arm, and arm64 are easy because Raspberry Pi's run those, but riscv on the other hand, is harder to come by.
I notice that the ARM and ARM64 platforms are supported. How come they are supported, what if any process was in place when choosing to support them?
These are supported because they're popular and a lot of people use these architectures. I don't think I have seen riscv arch being used really anywhere, which means that I don't have any knowledge about how common that arch actually is. I'm not sure what you mean with that last sentence, could you reword it?
With the QEMU and docker buildx CI setup, I got the impression that the project was open for other architectures.
I'm not opposing it per se, but I want to know why and how it would benefit the project. Basically cons and pros kind of thinking.
@olof-nord thank you for your contribution, we can attempt to build a riscv docker image and push it to the container registry, but we cannot guarantee much more than that. Is this sufficient?
Of course. Perhaps for now only building the 'latest' tag? As to indicate that it isn't officially supported.
Another idea might be to adjust the github bug issue template and note which architectures are supported, and which are provided as-is.
This Pull Request has been automatically marked as "stale" because it has not had recent activity (for 15 days). It will be closed if no further activity occurs. Thank you for your contribution.
Due to the lack of activity in the last 5 days since it was marked as "stale", we proceed to close this Pull Request. Do not hesitate to reopen it later if necessary.
Description of the change
This change introduces a fourth docker build architecture, RISC-V.
RISC-V is an open standard instruction set architecture (ISA) based on established reduced instruction set computer (RISC) principles. Unlike most other ISA designs, the RISC-V ISA is provided under open source licenses that do not require fees to use. A number of companies are offering or have announced RISC-V hardware, open source operating systems with RISC-V support are available and the instruction set is supported in several popular software toolchains. (from Wikipedia)
Benefits
As the CI pipeline already uses dockerx and QEMU (which both support RISCV already), I believe this introduction will be smooth.
The benefit of building images for riscv is that all projects which uses this docker image as a base image are closer to, or in an optimal case, already gain support for the new architecture.
Possible drawbacks
None really.
Applicable issues
I havent created an issue, as I thought I would give it a shot myself first.
Additional information
Ubuntu have supported RISC-V since the release of Ubuntu 20.04 LTS.
https://wiki.ubuntu.com/RISC-V