When I push my repository to Resin I get the following warning:
[Info] Starting Dockerfile build
[Build] Step 1 : FROM resin/raspberrypi3-python
[Build] # Executing 1 build trigger…
[Build] Step 1 : RUN echo ‘This repository is deprecated. Please check Balena base images - Balena Documentation for information about Resin docker images.’
[Build] —> Running in 4c9c213caddc
[Build] This repository is deprecated. Please check Balena base images - Balena Documentation for information about Resin docker images.
Everything seems to work correctly, but it looks ugly.
Trying to fix it leaves me with a couple of queries -
Q1: there seem to be 2 candidate base images that might be suitable - resin/raspberry-pi3-python or resin/raspberry-pi3-alpine-python. Since I am familiar with developing directly on an RPi running the Raspberry Pi Foundation’s Raspbian Jessie OS and libraries such as RPi.GPIO or GPIOZero am I right in thinking that and alpine-based solution with its different packaging manager would not be the right choice?
Q2: What RESIN_MACHINE_NAME variable should I be using in my Dockerfile.template to use the base image decided on in the previous query? There is no Raspberry Pi 3 support documented at https://docs.resin.io/deployment/docker-templates/
[I had to modify the text of the deprecation message to remove the active links because of the restriction imposed by the forum s/w.]
Hi, sorry for the confusion, it’s a change that touches on a number of parts of the platform, and not all the changes can be synchronized well in practice.
As you say “Everything seems to work correctly, but it looks ugly.” - at the moment it does not have any practical difference.
Looks like your questions are not really related to that deprecation note, though, or do I misunderstand something? You are asking what base image is the best for you? Whether Debian or Alpine works for you better, that depends on your application, and have to try things out yourself. That would also not have any effect on the note above, it’s not the Debian or Alpine images that are deprecated, but out resin/raspberrypi3-... images moving to the names resin/raspberry-p3-... to unify the naming convention.
If you are familiar with Debian, I would probably suggest work with that for the time being. You can also start from the Debian base image and install the Debian-provided Python packages, just like you would be doing on a normal Raspbian (our -python images are Python versions that we prepare so cover more versions that are normally available in Raspbian)
FROM resin/raspberrypi-pi3-debian:jessie
RUN apt-get update && apt-get install python3 <...and so on other dependencices>
If you are using a Dockerfile, use the raspberry-pi3-... images.
If you are using templates, those will continue working fine with %%RESIN_MACHINE_NAME%% (eg. FROM resin/%%RESIN_MACHINE_NAME%%-debian:jessie or FROM resin/%%RESIN_MACHINE_NAME%%-python), and while currently have the deprecation note, as you say there’s no difference, and these will switch to the new names shortly too.
I think they are absolutely and only related to the deprecation warning: in the absence of that warning there would be no problem to fix.
It seems you are saying that resin/raspberry-pi3-python is now the preferred name, but in practice equivalent to the ‘old’ resin/raspberrypi3-python form generated by the Dockerfile.template. That answers the first question.
For the second part of the question: how do I invoke that image in the FROM directive in the Dockerfile.template?
Using FROM resin/%%RESIN_MACHINE_NAME%%-python is known to give the ‘wrong’ (deprecated) result. Should I simply hard-code FROM resin/raspberry-pi3-python instead?
Or (more simply) should I conclude that the deprecation warning is just ‘noise’ and that in the fullness of time things will be tidied up by RESIN without me needing to change anything?
To clarify, at the moment on your side there’s no issue to fix. The deprecation warning is indeed that, a warning, not an error.
It’s because we are getting our base images and our building system (that interprets those template variables). It’s a chicken and egg problem, the new images have to be up before the templates can point to them, but have to be also clear that the old images won’t be used in the future hence the warning. It’s a transition stage, when both side works.
And I meant that choosing between Alpine and Debian is not really the issue here, but I see how it could be from your point of view
