5 ms·

Creating Debian packages from upstream Git

116 points by JNRowe 1y ago

dundarious 1y ago
Compare with Arch, e.g., https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gf2-git https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gf2-g..., where you just run `makepkg` or `makechrootpkg -r ~/archroot` (setup is just `mkdir -p ~/archroot ; mkarchroot ~/archroot/root base-devel`). The wiki is also wonderful (even for general-linux/non-Arch-specific information) -- informative and to-the-point.
- JNRowe 1y ago
  To be fair, if all you want is a package with Debian you can do that too. Just copy files in to a dir(like package() in your Arch example), write a 10 line DEBIAN/control in there(like the preamble in your Arch example), and call "dpkg-deb --build". The linked document is describing something different, joeyh has a short "why?"¹ from years ago that may be helpful. ¹ https://joeyh.name/blog/entry/upstream_git_repositories/ https://joeyh.name/blog/entry/upstream_git_repositories/
  - viraptor 1y ago
    Or use FPM and ignore all the official rules. It will still work. https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
  - dundarious 1y ago
    What is different in OP that makes that approach not suitable? The git upstream? In the AUR example I gave, pkgver() auto-updates $pkgver, which will show up in version control. You can run `makepkg -defo` (or -dfo I forget which rn) to just run pkgver().
- LtWorf 1y ago
  And will arch tell you that the package has updated the configuration and that you might want to review your canges with the changes from the new version? Will it automatially restart the .service file of the daemon you just upgraded? Will it autodetect which python modules it requires to install?
  - okanat 1y ago
    Arch/pacman will tell you config changes. There is even an utility called pacdiff to review all of them at once. It will not restart service files since it is a more hands-on distro. Since Arch is a quick rolling-release distro, it is better to reboot your system since ABI stability is not guaranteed. Arch/pacman packages are quite simple which makes the maintenance burden less. However, when compared to more mainstream distros like OpenSUSE and Fedora, Debian's package recipes are more unwieldy and arcane. Why do we need to put things in the upstream source in the first place? Why do we use scripts that don't make sense and full of legacy in 2025? I deal with Yocto almost daily, still most Debian packages are a mistery to me. Don't even mention things like getting an almost upstream Linux kernel (like a vanilla release + some patches on top) to be ported as a normal Debian package.
    - LtWorf 1y ago
      Is telling systemd to reload .service files after changing them a "script that doesn't make sense" to you? Makes plenty of sense to me. 90% of the scripts are to do that, or to recompile .pyc files when you install a new module or when you install a new version of python.
      - umbra07 1y ago
        Arch tries to generally avoid changing "default" behavior. Systemd doesn't automatically do that, so Arch won't ship systemd like that. Arch also generally avoids shipping with timers enabled.
        LtWorf 1y ago
        Out of lazyness or out of actual usefulness to the users?
        dpassens 1y ago
        I personally (using Arch, btw) definitely prefer Arch's behaviour. If I update or install a daemon, I generally want to configure it before (re)starting it.
mrweasel 1y ago
This is awesome, well, useful. I have a package I'd like to have in Debian, and I am willing to maintain it, but getting startet is just ... complex. The whole Debian package infrastructure is remarkable complete and capable, but it's dense and the documentation is not great. The git-buildpackage is barely documented, at least not in a manor which where a newbie can just build a package and be sure that an upgrade will work in the future.
- LtWorf 1y ago
  I think this is a good starting point https://mentors.debian.net/ https://mentors.debian.net/ Also personally I'd avoid using git buildpackage at the beginning since it's rather complicated and not everyone uses it (although those who do are very vocal!) You don't need git at all, but if you want something easier, create a repo on salsa and keep the debian/ directory there and that's it.
- ValdikSS 1y ago
  Can't agree more!! 10 years ago, when I wanted to package my utility, there were 3-4 documentation snippets, each of which usually used different set of utilities. - Should I create the package boilerplate with dh_make or debmake? The structure they create differs. - What's the name of command which I use to update the version in changelog? deb... no, dh_... no, ... it's `dch`! - You manage patches with `quilt`, but where do I get `dquilt` mentioned in the documentation? It's not in any package! Oh, it just an alias you should grab from `Chapter 3. Modifying the source` documentation and add into your .bashrc! And also `~/.quiltrc-dpkg`, or nothing would work. - Packaging: dpkg-buildpackage, debmake, or maybe pbuilder? - How do I append CFLAGS? It's DEB_CFLAGS_MAINT_APPEND, thanks dh_make comment inside the rule file! Too bad if you've created the structure with debmake! - dpkg-gensymbols: warning: some new symbols appeared in the symbols file - dh_missing: error: missing files, aborting But to Debian's credit, once you've done everything more or less correctly, you can use all the power of the build system. It's very easy to cross-compile software, just a matter of a single command. On other systems it's usually much harder.
denkmoon 1y ago
Just gonna share a tool I found recently that is really awesome for making debs, Debcraft (https://salsa.debian.org/debian/debcraft https://salsa.debian.org/debian/debcraft). It uses podman to isolate the build environment. The author of OP is also a major contributor, even though he barely mentions Debcraft in the post.
- dima55 1y ago
  sbuild is the tool used by the Debian community and all the Debian infrastructure to do this. Uses schroot under the hood, and is what you want instead of docker and friends 99% of the time anyway.
  - ottoke 1y ago
    Both sbuild and Debcraft essentially still run a minimal hermetic Debian environment without network access inside them. The fact that sbuild exists is not a reason to not try out Debcraft. However the selling point in Debcraft is not that it has the build environments, but much more.
  - denkmoon 1y ago
    Git clone from salsa [& making my changes,] then running `debcraft build` was a hell of a lot easier than even just reading the documentation for all the different ways to build debs. I don't want to be an expert in debian build and packaging systems, I just want to make a few debs for my lan, ideally without clobbering the build box in ways I don't really understand. I can't overstate how debcraft allowed me to glide over all that complexity and focus on the task I actually care about.
sevg 1y ago
The DEB format is powerful and has a lot of conveniences for Debian Developers (eg, it does lots of things automatically for you to reduce boilerplate). Unfortunately, it’s not easy to discover what automatic things are happening and what they’re doing. (If you look at the debian files for a package without packaging knowledge, you often can’t tell how the package is made. Arch Linux PKGBUILD files for example are much easier to understand without prior knowledge.) This isn’t necessarily a problem, but the documentation is poor as well, which means the barrier to entry is artificially high. At least that was my impression from a few years ago. Maybe things are better now.
pabs3 1y ago
Another way to do it; run debuild, fix the error, repeat. Then run lintian, fix the errors, repeat. Then upload to mentors, file a sponsor request, fix their comments, repeat. Then it gets a sponsored upload, but rejected with comments by ftp-masters, fix the errors repeat. Then it gets accepted, but users file bug reports, fix the error, repeat.
pornel 1y ago
I've always been intimidated by the number of little tools and configuration options when building Debian packages. In the end, it's not very hard, and the format is quite reasonable, it just feels more complicated than it is. I'm maintaining cargo-deb that builds a .deb from a Rust/Cargo binary project with no configuration needed.
- rleigh 1y ago
  The main source of complexity isn't the .deb format, but the tooling and infrastructure around the format. It's mired in overcomplexity, and it's very much still in a '90s mindset of building locally with multiple layers of Perl-based tools. If it was rethought to be git-native using docker images or equivalent then it could be of equivalent simplicity to other contemporary systems. When I look at what you can do with the FreeBSD ports and Poudriere or with Homebrew and other systems, I see how much of the complexity has been added incidentally and incrementally, with good intentions, but a radical rethink of the basic workflows are necessary to consolidate and simplify them. [I used to maintain sbuild and was the author of schroot back in the day]

116 points by JNRowe 1y ago

Compare with Arch, e.g., https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gf2-git https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=gf2-g..., where you just run `makepkg` or `makechrootpkg -r ~/archroot` (setup is just `mkdir -p ~/archroot ; mkarchroot ~/archroot/root base-devel`). The wiki is also wonderful (even for general-linux/non-Arch-specific information) -- informative and to-the-point.

JNRowe 1y ago
To be fair, if all you want is a package with Debian you can do that too. Just copy files in to a dir(like package() in your Arch example), write a 10 line DEBIAN/control in there(like the preamble in your Arch example), and call "dpkg-deb --build". The linked document is describing something different, joeyh has a short "why?"¹ from years ago that may be helpful. ¹ https://joeyh.name/blog/entry/upstream_git_repositories/ https://joeyh.name/blog/entry/upstream_git_repositories/
- viraptor 1y ago
  Or use FPM and ignore all the official rules. It will still work. https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
- dundarious 1y ago
  What is different in OP that makes that approach not suitable? The git upstream? In the AUR example I gave, pkgver() auto-updates $pkgver, which will show up in version control. You can run `makepkg -defo` (or -dfo I forget which rn) to just run pkgver().
LtWorf 1y ago
And will arch tell you that the package has updated the configuration and that you might want to review your canges with the changes from the new version? Will it automatially restart the .service file of the daemon you just upgraded? Will it autodetect which python modules it requires to install?
- okanat 1y ago
  Arch/pacman will tell you config changes. There is even an utility called pacdiff to review all of them at once. It will not restart service files since it is a more hands-on distro. Since Arch is a quick rolling-release distro, it is better to reboot your system since ABI stability is not guaranteed. Arch/pacman packages are quite simple which makes the maintenance burden less. However, when compared to more mainstream distros like OpenSUSE and Fedora, Debian's package recipes are more unwieldy and arcane. Why do we need to put things in the upstream source in the first place? Why do we use scripts that don't make sense and full of legacy in 2025? I deal with Yocto almost daily, still most Debian packages are a mistery to me. Don't even mention things like getting an almost upstream Linux kernel (like a vanilla release + some patches on top) to be ported as a normal Debian package.
  - LtWorf 1y ago
    Is telling systemd to reload .service files after changing them a "script that doesn't make sense" to you? Makes plenty of sense to me. 90% of the scripts are to do that, or to recompile .pyc files when you install a new module or when you install a new version of python.
    - umbra07 1y ago
      Arch tries to generally avoid changing "default" behavior. Systemd doesn't automatically do that, so Arch won't ship systemd like that. Arch also generally avoids shipping with timers enabled.
      - LtWorf 1y ago
        Out of lazyness or out of actual usefulness to the users?
        dpassens 1y ago
        I personally (using Arch, btw) definitely prefer Arch's behaviour. If I update or install a daemon, I generally want to configure it before (re)starting it.

mrweasel 1y ago

This is awesome, well, useful. I have a package I'd like to have in Debian, and I am willing to maintain it, but getting startet is just ... complex. The whole Debian package infrastructure is remarkable complete and capable, but it's dense and the documentation is not great. The git-buildpackage is barely documented, at least not in a manor which where a newbie can just build a package and be sure that an upgrade will work in the future.

LtWorf 1y ago
I think this is a good starting point https://mentors.debian.net/ https://mentors.debian.net/ Also personally I'd avoid using git buildpackage at the beginning since it's rather complicated and not everyone uses it (although those who do are very vocal!) You don't need git at all, but if you want something easier, create a repo on salsa and keep the debian/ directory there and that's it.
ValdikSS 1y ago
Can't agree more!! 10 years ago, when I wanted to package my utility, there were 3-4 documentation snippets, each of which usually used different set of utilities. - Should I create the package boilerplate with dh_make or debmake? The structure they create differs. - What's the name of command which I use to update the version in changelog? deb... no, dh_... no, ... it's `dch`! - You manage patches with `quilt`, but where do I get `dquilt` mentioned in the documentation? It's not in any package! Oh, it just an alias you should grab from `Chapter 3. Modifying the source` documentation and add into your .bashrc! And also `~/.quiltrc-dpkg`, or nothing would work. - Packaging: dpkg-buildpackage, debmake, or maybe pbuilder? - How do I append CFLAGS? It's DEB_CFLAGS_MAINT_APPEND, thanks dh_make comment inside the rule file! Too bad if you've created the structure with debmake! - dpkg-gensymbols: warning: some new symbols appeared in the symbols file - dh_missing: error: missing files, aborting But to Debian's credit, once you've done everything more or less correctly, you can use all the power of the build system. It's very easy to cross-compile software, just a matter of a single command. On other systems it's usually much harder.

denkmoon 1y ago

Just gonna share a tool I found recently that is really awesome for making debs, Debcraft (https://salsa.debian.org/debian/debcraft https://salsa.debian.org/debian/debcraft). It uses podman to isolate the build environment. The author of OP is also a major contributor, even though he barely mentions Debcraft in the post.

dima55 1y ago
sbuild is the tool used by the Debian community and all the Debian infrastructure to do this. Uses schroot under the hood, and is what you want instead of docker and friends 99% of the time anyway.
- ottoke 1y ago
  Both sbuild and Debcraft essentially still run a minimal hermetic Debian environment without network access inside them. The fact that sbuild exists is not a reason to not try out Debcraft. However the selling point in Debcraft is not that it has the build environments, but much more.
- denkmoon 1y ago
  Git clone from salsa [& making my changes,] then running `debcraft build` was a hell of a lot easier than even just reading the documentation for all the different ways to build debs. I don't want to be an expert in debian build and packaging systems, I just want to make a few debs for my lan, ideally without clobbering the build box in ways I don't really understand. I can't overstate how debcraft allowed me to glide over all that complexity and focus on the task I actually care about.

sevg 1y ago

The DEB format is powerful and has a lot of conveniences for Debian Developers (eg, it does lots of things automatically for you to reduce boilerplate). Unfortunately, it’s not easy to discover what automatic things are happening and what they’re doing. (If you look at the debian files for a package without packaging knowledge, you often can’t tell how the package is made. Arch Linux PKGBUILD files for example are much easier to understand without prior knowledge.) This isn’t necessarily a problem, but the documentation is poor as well, which means the barrier to entry is artificially high. At least that was my impression from a few years ago. Maybe things are better now.

pabs3 1y ago

Another way to do it; run debuild, fix the error, repeat. Then run lintian, fix the errors, repeat. Then upload to mentors, file a sponsor request, fix their comments, repeat. Then it gets a sponsored upload, but rejected with comments by ftp-masters, fix the errors repeat. Then it gets accepted, but users file bug reports, fix the error, repeat.

pornel 1y ago

I've always been intimidated by the number of little tools and configuration options when building Debian packages. In the end, it's not very hard, and the format is quite reasonable, it just feels more complicated than it is. I'm maintaining cargo-deb that builds a .deb from a Rust/Cargo binary project with no configuration needed.

rleigh 1y ago
The main source of complexity isn't the .deb format, but the tooling and infrastructure around the format. It's mired in overcomplexity, and it's very much still in a '90s mindset of building locally with multiple layers of Perl-based tools. If it was rethought to be git-native using docker images or equivalent then it could be of equivalent simplicity to other contemporary systems. When I look at what you can do with the FreeBSD ports and Poudriere or with Homebrew and other systems, I see how much of the complexity has been added incidentally and incrementally, with good intentions, but a radical rethink of the basic workflows are necessary to consolidate and simplify them. [I used to maintain sbuild and was the author of schroot back in the day]