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

@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?

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

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.

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.

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

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.