Docker-alpine: Subversion

[LukasBacigal]

Are you going to support subversion of alpine?
Such as 3.3.1 or 3.3.2 as seen on http://www.alpinelinux.org/

EDIT [1]:
In case the new version overlap with image used in Dockerfile of course.

[andyshinn]

Can you clarify the question? I am not sure what is being asked.

[frol]

@LukasBacigal There seem to be no changes in 3.3.2 and 3.3.3 Alpine releases to the packages that are used in this image: alpine-baselayout, alpine-keys, apk-tools, libc-utils. Thus, there is no need to rebuild the image. However, it might be necessary to rebuild the images based on Alpine image.

[frol]

See also a related issue #129.

[LukasBacigal]

@frol That's exactly where I was going, thanks. As seen below:

Basic image contains those packages:
musl-1.1.12-r1
busybox-1.24.1-r7
alpine-baselayout-2.3.2-r10
alpine-keys-1.1-r0
zlib-1.2.8-r2
libcrypto1.0-1.0.2e-r0
libssl1.0-1.0.2e-r0
apk-tools-2.6.5-r1
scanelf-0.9.1-r0
musl-utils-1.1.12-r1
libc-utils-0.7-r0

And it looks like some of them have newer versions in newer images.

apk -U version
fetch http://dl-4.alpinelinux.org/alpine/v3.3/main/x86_64/APKINDEX.tar.gz
fetch http://dl-4.alpinelinux.org/alpine/v3.3/community/x86_64/APKINDEX.tar.gz

| Installed: | Available: |
| --- | --- |
| libcrypto1.0-1.0.2e-r0 | < 1.0.2g-r0 |
| musl-1.1.12-r1 | < 1.1.12-r3 |
| musl-utils-1.1.12-r1 | < 1.1.12-r3 |
| libssl1.0-1.0.2e-r0 | < 1.0.2g-r0 |

[frol]

@andyshinn It seems that Official Alpine image has not been upgraded after newer libcrypto and libssl released:

$ docker run -it --rm alpine sh
/ # apk update
fetch http://dl-4.alpinelinux.org/alpine/v3.3/main/x86_64/APKINDEX.tar.gz
defetch http://dl-4.alpinelinux.org/alpine/v3.3/community/x86_64/APKINDEX.tar.gz
v3.3.3-8-gaa90166 [http://dl-4.alpinelinux.org/alpine/v3.3/main]
v3.3.1-122-g47d8282 [http://dl-4.alpinelinux.org/alpine/v3.3/community]
OK: 5860 distinct packages available

/ # apk upgrade
(1/4) Upgrading musl (1.1.12-r1 -> 1.1.12-r3)
(2/4) Upgrading libcrypto1.0 (1.0.2e-r0 -> 1.0.2g-r0)
(3/4) Upgrading libssl1.0 (1.0.2e-r0 -> 1.0.2g-r0)
(4/4) Upgrading musl-utils (1.1.12-r1 -> 1.1.12-r3)
Executing busybox-1.24.1-r7.trigger
OK: 5 MiB in 11 packages

Notice that only a minor upgrade is available for musl libc in gliderlabs/alpine image:

$ docker run -it --rm gliderlabs/alpine sh
/ # apk update
fetch http://alpine.gliderlabs.com/alpine/v3.3/main/x86_64/APKINDEX.tar.gz
fetch http://alpine.gliderlabs.com/alpine/v3.3/community/x86_64/APKINDEX.tar.gz
v3.3.3-8-gaa90166 [http://alpine.gliderlabs.com/alpine/v3.3/main]
v3.3.1-122-g47d8282 [http://alpine.gliderlabs.com/alpine/v3.3/community]
OK: 5858 distinct packages available

/ # apk upgrade
(1/2) Upgrading musl (1.1.12-r2 -> 1.1.12-r3)
(2/2) Upgrading musl-utils (1.1.12-r2 -> 1.1.12-r3)
Executing busybox-1.24.1-r7.trigger
OK: 5 MiB in 11 packages

[LukasBacigal]

Is this going to "rewrite" alpine:3.3 or make some subversion like alpine:3.3.3

[frol]

@LukasBacigal It will replace alpine:3.3 since the last digit in the version is used to indicate that important bug-fixes released rather than big changes.

[LukasBacigal]

There is reason why even docker makes subversion, and that's because people expect some exact behaviour from they current version and using
FROM alpine:3.3 should use same image everytime, on the other hand those SHOULD be ONLY bugfixes which seems ok for me.
In the end you guys are "managers" of this docker image so in final it is your decision. And I expect we can close this issue.

[frol]

@LukasBacigal I'm not a "manager" of this docker image, I'm just a stranger with some interest in this image. Thus, as far as I know, the decision maker is only @andyshinn here. I would expect alpine:3.3 gets all updates from 3.3.x series because even if the image would be frozen, say, at 3.3.0 release, the repository is the same for all 3.3.x series, and you will inadvertently produce different result anyway.

[andyshinn]

The main reason we are not pushing patch level versions is that the repositories don't allow us to pin to a patch level. As an example, we wouldn't have any reasonable way to rebuild 3.3.1 or 3.3.2 images since they build from the 3.3 repository. At the end of the day rebuilding those images right now would make them the same (essentially whatever 3.3 was at that time).

Though, I do agree that overwriting the same tag with patch level changes is not ideal. I'm open to building in some changes to the build script to allow us to push minor revisions. But I haven't really seen the need or use case yet.

Right now, I equate it similarly to how you may base your image on ubuntu:14.04. But the 14.04 tag will roll to the next patch level or change when security backports are pushed. So it isn't completely out of the norm in the Docker ecosystem.

[frol]

@andyshinn Could you please bump the Official Alpine image so it gets libssl and libcrypto packages?

[andyshinn]

Can you open another issue about that? I'm not seeing those specific ones outdated:

$ d pull alpine
latest: Pulling from alpine
2a250d324882: Pull complete 
Digest: sha256:7739b19a213f3a0aa8dacbd5898c8bd467e6eaf71074296a3d75824e76257396
Status: Downloaded newer image for alpine:latest
$ d run --rm alpine apk -U version
fetch http://dl-cdn.alpinelinux.org/alpine/v3.3/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.3/community/x86_64/APKINDEX.tar.gz
Installed:                                Available:
musl-1.1.12-r2                          < 1.1.12-r3 
musl-utils-1.1.12-r2                    < 1.1.12-r3

[frol]

Hmm, it is indeed up-to-date; I must have messed things up yesterday. Sorry for that.