search

nunofgs / docker-octoprint

Dockerfile to set up Octoprint with x86, armv6, armv7 and arm64 support!
https://hub.docker.com/r/nunofgs/octoprint/
GNU Affero General Public License v3.0
58 stars 32 forks source link

seem to have silently dropped arm32v6 support ? #19

Closed aleks-mariusz closed 5 years ago

aleks-mariusz commented 5 years ago

So I notice that when this commit was made, you also changed all occurrences of arm32v6 to arm32v7, thus effectively dropping support for arm32v6 platforms (i say silently since the commit message doesn't mention any reference to this).

Not sure if ditching arm32v6 was intentional or only planned to only be temporary, or perhaps was on purpose and the documentation just didn't get updated, but i have a wonderful Raspberry Pi v1, model B, (one of the first off the original production line) and because of the above mentioned change, the "newer" image tag i can run from your repo is only 1.3.8-arm32v6 from last summer, since everything newer requires arm32v7 and my Pi can't run those :-(

However judging from the commit message itself, seems perhaps this was unintentional (or at least just a sub-optimal side-effect) which only was required because you moved from an Alpine to Debian base image (any reason for that?). These days however, there is a modern arm32v6 alpine image available, presuming alpine itself wasn't the problem..

So while perhaps Debian provides a lot more options for packages, the Alpine is still preferable (for me at least), as the I/O performance on the Pi (such as what's necessary when pulling/running images) is a bit underwhelming.

Any chance you could continue to once again build an alpine-based image, or at very least one that still runs on arm32v6 ?

nunofgs commented 5 years ago

Hi @aleks-mariusz,

First of all let me apologize for leaving this issue open for so long without a reply. Definitely not friendly on my part. My daily life was/is taking precedence but I will do better :)

Now, you're correct that I did drop armv6 support a while ago. At the time my reasons were:

  1. I wasn't using it (I didn't even have a rpi zero to test at the time)
  2. I wanted to build an actual armv7 image and not rely on CPU backwards-compatibility, mainly for performance reasons (even though I don't think it made much of a difference).
  3. In moving to armv7 I wasn't able to keep support for armv6 because, at the time, armv7/python didn't actually have an alpine variant. [they have since added one]

I too personally prefer alpine over debian for Docker images so I just pushed a PR which will add an alpine variant to my repository. (see #23)

For now I'm keeping debian as the "main" image (ie: latest, 1.3.xx, etc.) just to avoid breaking things for users of this image which, as of today, total 1M+ monthly downloads (not bad! 😎)

I'll announce a switch to alpine as the "main" image on the README.md soon to give adequate time for users to be prepared.