Repository navigation
switch to buildpack-deps-scm+gcc for the default variant #4
Description
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 nodenode + what's necessary to build C deps + debianFROM node:buildpacknode + popular C libraries + debianFROM node:slimnode + busybox-opkg? or evenSCRATCH? :)
What do you think?
/cc @tianon @automaticali
Activity
chorrell commentedon Feb 4, 2015
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/librariesThe trick is figuring out what needs to be installed on top of buildpack-deps:jessie-scm
proppy commentedon Feb 4, 2015
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 commentedon Feb 4, 2015
I wonder if npm has some publicly available stats that could help here?
proppy commentedon Feb 4, 2015
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 commentedon Feb 4, 2015
proppy commentedon Feb 7, 2015
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 commentedon Feb 10, 2015
Oh, that's unfortunate 😞
camerondavison commentedon Oct 23, 2015
it would be at least nice to move to the -scm buildpack deps so that git uris work in package.json
chorrell commentedon Oct 23, 2015
Oh, they don't currently work in the default variant? That's surprising since it uses
buildpack-depsandbuildpack-depsis based off ofbuildpack-deps:jessie-scm.Starefossen commentedon Oct 23, 2015
GIT should work in the normal one, but maybe not in the
:slimvariant.camerondavison commentedon Oct 23, 2015
oh I was using the slim. sorry about that.
chorrell commentedon Oct 23, 2015
Ah, ok that explains it :)
retrohacker commentedon Mar 4, 2016
This appears to be two separate issues.
buildpacksfor each of the images we support.Would basing off of something other than the default
buildpacksbe large enough of a win in size to justify adding 4 additional tags to this repo?chorrell commentedon Mar 4, 2016
I think the original the request was to change the base images to use
buildpack-deps:jessie-scmrather than currentbuildpack-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:jessiefor the foreseeable future. One thing we could consider is switching the next major release (Node.js v6.x.x) to use thebuildpack-deps:jessie-scmand highlight as a breaking change.chorrell commentedon Jun 3, 2016
Are we ok to close this out?
I think ultimately we decided that we can't switch to
buildpack-deps:jessie-scmdue to possible breakage and the slim variant addresses (and eventual Alpine variant) addresses the image size concerns.polarathene commentedon Jun 14, 2016
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 commentedon Jun 14, 2016
@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:jessiewithFROM buildpack-deps:stretch).chorrell commentedon Apr 7, 2017
Closing this out since switching to buildpack-deps:jessie-scm would lead breakage and the slim and alpine variants address the image size concerns.