[RFC] Add 3.5/alpine variant

[ncopa]

This is an alpine linux variant of python 3.5.

I have a few questions and comments:

• do we call it "alpine"? or "musl"? or something else?
• i remove the gnupg tool, which the debian variant(s) does not do. it this ok?
• I currently base this on alpine:edge, but we probably want to use alpine:latest (after v3.3 is released).
• I use scanelf to identify the runtime deps. This is to protect those from being uninstalled by accident. Do we want this extra complexity?

/ # apk info -R .python-rundeps
WARNING: Ignoring APKINDEX.ed54c246.tar.gz: No such file or directory
.python-rundeps-0 depends on:
so:libbz2.so.1
so:libc.musl-x86_64.so.1
so:libcrypto.so.1.0.0
so:libncursesw.so.6
so:libpanelw.so.6
so:libsqlite3.so.0
so:libssl.so.1.0.0
so:libz.so.1

/ # apk del zlib
WARNING: Ignoring APKINDEX.ed54c246.tar.gz: No such file or directory
World updated, but the following packages are not removed due to:
  zlib: libcrypto1.0 apk-tools alpine-base .python-rundeps libssl1.0

OK: 14 MiB in 25 packages
/ # 

[tianon]

Nice start! 👍

1. definitely alpine (since we've already set that precedent, and I think it has more meaning and conveys more useful knowledge in general to the end-users of the image than musl does)
2. I'm totally all for removing gpg after we've done our verification (and even moving the install, key fetch, and remove all into that same build step to make sure we don't pay the cost of space unnecessarily) -- just leave an ENV GPG_KEY 97FC712E4C024BBEA48A61ED3A5CA953F73C700D where the current --recv-key line is, since that's something we'll need to mutate for different Python versions
3. yeah, we definitely don't want to have an official image targeting alpine:edge for the same reason we don't really have any targeting debian:sid 😄 -- any particular bits in Alpine 3.3 that this requires which make 3.2 not suitable?
4. IMO, scanelf is a brilliant and effective solution; let's roll with it! 👍

BTW, if you add - VERSION=3.5 VARIANT=alpine in the env: block of .travis.yml, we'll get this Dockerfile actually being built in Travis. 😄

[Starefossen]

@tianon we have had a similar discussion whether we should add an alpine variant to the official Node.js image nodejs/docker-iojs#44 and nodejs/docker-iojs#80. Our main concern is that the Node.js test suite is currently not run against alpine, and we feel that including an untested base for an official image is generally a bad practice. Any thoughts on this?

[tianon]

@Starefossen yeah, it's definitely a good concern to have -- IMO, folks should know they're walking into uncharted waters a little bit, and the description we added for alpine variants (when golang got one) does talk about that: https://github.com/docker-library/docs/blob/3163284bc3b247deba25150e844083fd2f4f011f/.template-helpers/variant-alpine.md

Reading through it again, the caveat could probably use a little strengthening and specifically mention that upstream isn't likely to be doing a lot of their own testing against an Alpine base distribution.

[tianon]

To summarize a bit more clearly, I think this is OK as long as we make it clear to the users that they may or may not run into bizarre issues while doing using these variants, and that their relevant upstream may not be willing to support them.

[Starefossen]

Thanks for the clarification @tianon. There is obviously a strong desire amongst many for a slimmer alpine-like variant for most of the official images on Docker Hub.

[tianon]

Yeah, I'd say I'm a fan since it makes it a lot easier to make really slim images without having to go as crazy as fully-static + FROM scratch, and they still have a decent POSIX shell included to boot (not to mention an actual package manager), but I think we need to be somewhat cautious in the way we present these variants to our users (so I'd really appreciate help making that variant description more clearly spell out the caveats, especially if we can find some good references of other people describing in more detail the kinds of issues that might come up).

[ncopa]

whoops. I deleted the branch by mistake. i create a new pull request.

[ncopa]

any particular bits in Alpine 3.3 that this requires which make 3.2 not suitable?

I think there are 2 minor but significant improvements:

• apk add --no-cache
• busybox su support for /etc/securetty

The latter means that you cannot use su to elevate privileges if root has no password.

Those does not affect this docker image directly though.