riotdocker icon indicating copy to clipboard operation
riotdocker copied to clipboard

Provide support for other Linux distributions

Open miri64 opened this issue 6 years ago • 6 comments

Our community uses a variety of Linux distributions (if they use it at all): Arch, Ubuntu, Debian, Alpine, just to name a few I heard of. So I was thinking to help better understand a contributor to understand problems on other distributions to also provide Dockerfiles for those. For most debian-based distributions the integration should be pretty easy, because it should be pretty much the same as our current Dockerfile (which I would leave as a default). For others, AFAIS only the apt-get run needs to be changed. What do you think?

miri64 avatar Jan 25 '19 15:01 miri64

Dockerfiles for those

you mean, Dockerfiles using the other distributions internally? Sounds useful, but also like a lot of maintenance work.

kaspar030 avatar Jan 25 '19 21:01 kaspar030

If you want to have a look, I have a branch which uses fedora as the base, but I never PRed it because it became larger than the current master docker image. Supporting more distros will increase the maintenance burden, and I doubt it will be very useful since we are using mostly vendor toolchains which should work the same regardless of the underlying distro.

Anyway, here is the fedora branch: https://github.com/gebart/riotdocker/tree/pr/fedora?files=1

jnohlgard avatar Jan 26 '19 09:01 jnohlgard

One option would be to move the vendor toolchain installations into scripts (e.g., one for arm, one for riscv, ...), together with information on dependencies. The latter could be done for multiple repos.

E.g.,

install-risc-v.sh:

install_deps_ubuntu() {
  apt-get install -y foo bar gcc binutils python3
}

install_deps_fedore() {
 yum install foo-devel bar-fedora-name ...
}
install() {
 local target=${1:/opt/riscv}

 wget file
 untar ...
}

But it feels like devising a cross-distro packaging solution...

kaspar030 avatar Jan 28 '19 09:01 kaspar030

If the purpose of the "alternate images" is to emulate what would happen on a developer's PC with that OS, then it is important that the tools are installed via the default method for that OS, with the default versions for that OS.

Right now, the riotdocker is serving two combined purposes:

  1. Provide an easy to set up build environment (for users and devs)
  2. Serve as an Ubuntu test image (since Ubuntu us the "official OS" for developing RIOT).

The purpose of alternate images would only be to serve as test image (2).

A couple of questions:

  • When will building on these alternate images be done, and who will do it?
  • What happens when RIOT fails on one of these images.

jcarrano avatar Feb 06 '19 14:02 jcarrano

  • When will building on these alternate images be done, and who will do it?

No idea of docker, I always assumed there is some magic happening @ dockerhub to make this happening.

  • What happens when RIOT fails on one of these images.

since my intention with this discussion was to go more into the direction of (2), my answer is: someone needs to fix it. For me this is more about reproducing another contributors experience quickly than about having "official" support for different OSs.

miri64 avatar Feb 06 '19 15:02 miri64

No idea of docker, I always assumed there is some magic happening @ dockerhub to make this happening.

Yes, but that is building the image. I was referring to building RIOT using that image.

For me this is more about reproducing another contributors experience quickly than about having "official" support for different OSs.

Ok, agree. The issue is that without regular maintenance the build may stop working or the images may fall behind the contributors PCs. I'm not saying it has to be tested in the CI or anything like that, it can be tested independently.

jcarrano avatar Feb 06 '19 16:02 jcarrano