-
Notifications
You must be signed in to change notification settings - Fork 58
Add Dockerfile for build deb-package (Ubuntu 24.04) #316
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.