Skip to content

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

Open
wants to merge 4 commits into
base: master
Choose a base branch
from

Conversation

DayDve
Copy link

@DayDve DayDve commented Jul 2, 2025

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.

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.
Comment on lines 4 to 6
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 \
Copy link
Owner

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?

Copy link
Author

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.

Copy link
Owner

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.

Copy link
Author

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.

@DayDve DayDve requested a review from Zygo July 9, 2025 16:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants