Add Dockerfile for build deb-package (Ubuntu 24.04)#316
Add Dockerfile for build deb-package (Ubuntu 24.04)#316DayDve wants to merge 4 commits intoZygo:masterfrom
Conversation
Just use this command: ``` docker buildx build \ --platform linux/amd64 \ -t bees-deb \ --build-arg "DEBFULLNAME=Your Name" \ --build-arg "DEBEMAIL=your@email" \ -f ./Dockerfile_buildx_deb \ --output type=local,dest=./deb . ``` After this, the bees installation deb package will appear in the ./deb directory.
Dockerfile_buildx_deb
Outdated
| fakeroot=1.33-1 git=1:2.43.0-1ubuntu7.2 build-essential=12.10ubuntu1 \ | ||
| devscripts=2.23.7 debhelper=13.14.1ubuntu5 dh-make=2.202304 \ | ||
| btrfs-progs=6.6.3-1.1build2 markdown=1.0.1-12 pkg-config=1.8.1-2build1 \ |
There was a problem hiding this comment.
Does hardcoding the versions here mean we have to keep updating this file, e.g. if there's a security release for git?
There was a problem hiding this comment.
I understand the concern about hardcoding versions.
My main goal with this Dockerfile was to make the build reproducible and automatable, rather than having to install everything manually.
By pinning versions, I ensured that the image builds and works the same way even if package versions change upstream — which is especially important for reliable .deb package builds.
This Dockerfile is meant to reflect the state of the build environment at the time it was working, not to track future updates.
I'm not planning to maintain or regularly update these versions — the idea is to have a fixed, known-good base.
If in the future a security update is needed, someone can of course update the relevant version(s) — but that's outside the scope of this PR.
There was a problem hiding this comment.
By pinning versions, I ensured that the image builds and works the same way even if package versions change upstream — which is especially important for reliable .deb package builds.
Sure, but ubuntu drops the old versions when there's an upgrade, and with git in particular, upgrades happen several times a year.
The guarantee you get from the Dockerfile is "you can build exactly this version, or you can build nothing at all," and the "nothing at all" will likely happen before the end of 2025. This seems very short-lived, when the same command line without hardcoded versions would work for all of the last 6 years, and likely continue to work until the EOL for 24.04 in 2029.
You haven't pinned the base version to a digest, so you're not even getting a reproducible build for all this ongoing maintenance requirement.
There was a problem hiding this comment.
I removed the version pinning from apt-get install, as suggested, to reduce long-term maintenance cost and to ensure compatibility with future package updates in Ubuntu 24.04.
That said, just for context:
the original version pinning was intentionally added to provide a minimum level of build reproducibility — to ensure that the resulting DEB could be built consistently at the time the Dockerfile was written.
This pattern is also recommended by tools like hadolint (see rule DL3008), which warns when packages are installed without pinned versions, since it can lead to non-reproducible or unpredictable builds when upstream repositories change.
I understand that maintaining pinned versions over time can be a burden — and I agree it's better to drop them unless reproducibility is a hard requirement.
I just opened this PR to share a working example of a Docker-based build setup — no pressure to accept it as-is.
Feel free to tweak or rewrite it however you prefer.
Just use this command:
After this, the bees installation deb package will appear in the ./deb directory.