At the outset, I'll mention this investigation was aided by codex, so if there are alternate things/methods we could use to confirm this has no change in behavior, I will happily close this PR and do that instead. :saluting_face:
Updates in this commit:
- Clean apt metadata after apt installs in
Dockerfile. - Remove the downloaded code-server
.debafter install inget-code-server.sh. - Install apt packages with
--no-install-recommendsinDockerfile.
It looks like this cuts off around 181MB from the final image size.
The approach to validate that there was no change in behavior:
- Built a temporary variant using
apt-get install -y --no-install-recommendsfor the two apt install blocks. - Package list comparison (
dpkg-query -Wsorted, blank lines removed) between the baseline image and the--no-install-recommendsvariant showed no differences. - Size delta from
--no-install-recommendsalone: ~42.6MB (~3.5%).
Rationale for no behavior change:
- Identical dpkg package sets mean the runtime and CLI surface is unchanged.
- Only the apt resolver behavior changed; it did not affect the final installed packages in this build.
Activity
41
lpmi-138mo agoif this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.
lpmi-138mo agoif this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.
lpmi-138mo agoif this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.
lpmi-138mo agoif this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.
lpmi-138mo agoif this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.
lpmi-138mo agoif this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.
lpmi-138mo agoif this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.
lpmi-138mo agoif this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
lpmi-138mo agoIt's a fair point, and I think I was approaching it from a containerized runtime bias.
I suppose the only potential argument for none of the recommends is that anybody who wanted that stuff would have an easier time installing what was missing into a custom rootFS than removing what they didn't need. However, in that case, they should probably just use their own custom base anyway and wouldn't even use this to begin with.
Removing the deb seems still helpful though, since it's bytes we don't need to pull across the wire. And I don't think there's any conceivable reason somebody might want/need it there.
If that sounds sensible, I can easily rebase that to be the only diff...but also can just close this, not withered either way.
if this ends up getting approval, I would happily submit further PRs to slim down more images in this repo.