search

docker-library / buildpack-deps

MIT License
445 stars 113 forks source link

why buildpack-deps:stretch is much larger than buildpack-deps:jessie ? (by 210MB) #64

Closed c0b closed 6 years ago

c0b commented 7 years ago

has anybody researched why is this? I see majority of downstream images are still based on buildpack-deps:jessie I believe this larger size hinders adoption of buildpack-deps:stretch

$ docker image ls buildpack-deps
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
buildpack-deps      latest              223c9ecff8eb        4 weeks ago         826MB
buildpack-deps      stretch             223c9ecff8eb        4 weeks ago         826MB
buildpack-deps      stretch-scm         8b8559aff3a2        4 weeks ago         273MB
buildpack-deps      stretch-curl        6b9f0849e499        4 weeks ago         131MB
buildpack-deps      jessie              a00998d35d0b        4 weeks ago         610MB
buildpack-deps      jessie-scm          3f8223a87be8        4 weeks ago         291MB
buildpack-deps      jessie-curl         6eff593c35dd        4 weeks ago         168MB
tianon commented 7 years ago

Yeah, that's definitely worth looking into -- checking which packages get installed in each via deps might be a good place to start digging (before getting crazy with diffing rootfs contents directly).

krmcbride commented 6 years ago

I was curious about this as well so looked into it a little. The culprit appears to be libmagickcore-dev (and libmagickwand-dev).

It looks like about half of the additional ~200MB is coming from libicu-dev being pulled in.

tianon commented 6 years ago

Closing, since this isn't an issue with the image, and is more an issue with Debian's packaging / dependencies changing between stretch and jessie (as noted above). :+1: