Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide support for other Linux distributions #66

Open
miri64 opened this issue Jan 25, 2019 · 6 comments
Open

Provide support for other Linux distributions #66

miri64 opened this issue Jan 25, 2019 · 6 comments
Labels

Comments

@miri64
Copy link
Member

miri64 commented Jan 25, 2019

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?

@kaspar030
Copy link
Contributor

Dockerfiles for those

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

@jnohlgard
Copy link
Member

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

@kaspar030
Copy link
Contributor

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...

@jcarrano
Copy link
Contributor

jcarrano commented Feb 6, 2019

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.

@miri64
Copy link
Member Author

miri64 commented Feb 6, 2019

  • 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.

@jcarrano
Copy link
Contributor

jcarrano commented Feb 6, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants