switch to buildpack-deps-scm+gcc for the default variant

[proppy]

Now that we have more granular buildpack-deps, I'd like to discuss switching to buildpack-scm+gcc (and maybe later buildpack-gcc see docker-library/buildpack-deps#17) for the default variant.

The rational I'd like to defend here, is that user of the default image should never have to modify their Dockerfile in order to npm install self contained native dependencies that doesn't require a 3rd party library/headers, but that paying the tax of 400MB of C libraries (currently in buildpack-deps) you might not care about could be a hard price to pay (both for the first pull/push) for that "feature"

The :slim version is not really a good fit either, as figuring out the set of dependencies for build C extensions to add on top (after #2 was merged) is not necessarily well know of casual users.

It sounds like it could be useful to provide a more granular base image offering:

• FROM node node + what's necessary to build C deps + debian
• FROM node:buildpack node + popular C libraries + debian
• FROM node:slim node + busybox-opkg? or even SCRATCH? :)

What do you think?

/cc @tianon @automaticali

[chorrell]

I like the idea of trimming things down. buildpack-deps is pretty big.

I lean towards something like FROM buildpack-deps:jessie-scm + C deps/libraries

The trick is figuring out what needs to be installed on top of buildpack-deps:jessie-scm

[proppy]

The trick is figuring out what needs to be installed on top of buildpack-deps:jessie-scm

I think at minimum we want gcc + what's strictly required to build a node package with some cpp code in it (v8 headers?).

You might want to extend that to commonly used C library, but I think that's a subset that is difficult to infer unless you run some stats on the whole npm archive dependency tree.

[chorrell]

I wonder if npm has some publicly available stats that could help here?

[proppy]

It seems that one could replicate the archive from https://skimdb.npmjs.com/registry to a local couchdb, and run some mapreduce on it :)

See http://blog.npmjs.org/post/75707294465/new-npm-registry-architecture

[tianon]

It's so easy, @proppy is volunteering to do it. 😉

[proppy]

Actually it seems that npm/package.json doesn't surface native dependencies, see for example:
https://github.com/aheckmann/gm/blob/master/package.json

[chorrell]

Oh, that's unfortunate 😞

[camerondavison]

it would be at least nice to move to the -scm buildpack deps so that git uris work in package.json

[chorrell]

Oh, they don't currently work in the default variant? That's surprising since it uses buildpack-deps and buildpack-deps is based off of buildpack-deps:jessie-scm.

[Starefossen]

GIT should work in the normal one, but maybe not in the :slim variant.

[camerondavison]

oh I was using the slim. sorry about that.

[chorrell]

Ah, ok that explains it :)

[retrohacker]

This appears to be two separate issues.

1. Strip out common C libraries from the base image and add a separate tag buildpacks for each of the images we support.
2. Add an Alpine variant? #46

Would basing off of something other than the default buildpacks be large enough of a win in size to justify adding 4 additional tags to this repo?

[chorrell]

I think the original the request was to change the base images to use buildpack-deps:jessie-scm rather than current buildpack-deps:jessie , but that would probably break things for a lot of people who use the current image.

The slim variant and the eventual Alpine variant pretty much address the image size issue though.

I think, in terms of the current base images, we're stuck with buildpack-deps:jessie for the foreseeable future. One thing we could consider is switching the next major release (Node.js v6.x.x) to use the buildpack-deps:jessie-scm and highlight as a breaking change.

[chorrell]

Are we ok to close this out?

I think ultimately we decided that we can't switch to buildpack-deps:jessie-scm due to possible breakage and the slim variant addresses (and eventual Alpine variant) addresses the image size concerns.

[polarathene]

I just ran into an issue with node-openzwave-shared which depends on compiling OpenZWave. I've tracked this down to Debian Jessie GCC package being one version behind what was needed I think. I've been looking around how to fix this but not had much luck, seems I might need to use Stretch or find some way to get GCC5 installed instead, is there a suitable official node docker image for this?

I raised an issue on the repo if any of the information helps clarify the problem.

[pesho]

@polarathene there is no official Node image with Stretch. You could try modifying the Jessie Dockerfile and building such an image yourself (replace FROM buildpack-deps:jessie with FROM buildpack-deps:stretch).

[chorrell]

Closing this out since switching to buildpack-deps:jessie-scm would lead breakage and the slim and alpine variants address the image size concerns.