5 ms·

Debian Packaging Tutorial – Feedback Welcome

44 points by ssundarraj 11y ago

zlatan_todoric 11y ago
Being a Debian maintainer, that is a very bad and low quality tutorial. You missed a lot of files in debian directory, even your example of control file is not good enough, you're using practices to build package which would reject your package from even entering Debian. Also lintian is a must be if you work with Debian (and it would really scream with your tutorial). Better tutorials: https://wiki.debian.org/IntroDebianPackaging https://wiki.debian.org/IntroDebianPackaging https://wiki.debian.org/HowToPackageForDebian https://wiki.debian.org/HowToPackageForDebian https://people.debian.org/~osamu/maint-guide.html https://people.debian.org/~osamu/maint-guide.html https://wiki.debian.org/PackagingWithGit https://wiki.debian.org/PackagingWithGit (because we are all going to git the world).
- rahiel 11y ago
  If on the other hand your goal is not to get a package in Debian, but only to quickly make a deb file, check out fpm: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm.
  - zlatan_todoric 11y ago
    Yep, the tutorial name should be how to quickly (low quality) create a deb package from simple source. :) Also you can use equivs for creating quick (dummy?) packages :D
    - brudgers 11y ago
      The link to other resources and the expertise expressed in the head comment of this thread was helpful. The insults are not.
      - zlatan_todoric 11y ago
        what insults?
- regularfry 11y ago
  As a Debian user, it's a fine tutorial. Not every .deb is built for distribution with Debian itself. The only change I'd make is to clarify that what's being built here is a "for personal use only" package. As to the debian.org guides, I've always found them obtuse precisely because they emphasise what you've got to do to get a package distributed, rather than the plain technical details of how they work.
  - zlatan_todoric 11y ago
    Packaging tutorial shouldn't be technical details how deb package works but how you build one (if you want those details you can also find them in Debian documentation but in the end deb package is just an ar file with it's set of make file that satisfies the installation in specific distro - this is the simple explanation). And no, the tutorial is misleading because Debian packaging means doing it for Debian, while creating a deb package for your personal need is different. You also have Ubuntu packaging guides and so on.
    - regularfry 11y ago
      But the guides aren't just how you build a package. They're how you package something for official distribution. The requirements for the former aren't nearly as stringent as for the latter, and by obscuring the former behind the latter, Debian makes its packaging guides less useful.
      - zlatan_todoric 11y ago
        Debian packaging guides are less useful because they concentrate on how to build package for Debian? And nobody is hiding from you any tutorial - Debian is an open community and the wiki is open to everyone so you can search for what you need but I really don't see the point in your sentences (are you saying that we should favorite somehow quick and dirty hacks instead of our strict high-quality ways of building packages? Because if yes, then Debian wouldn't be what it is today...)
        11y ago
- ssundarraj 11y ago
  Those are definitely better links, but a while back I needed a quick guide to make something that worked on private servers. I couldn't find a quickstart guide, so I decided to make one. Thanks for the feedback!
  - zlatan_todoric 11y ago
    You really should take more care of servers :) What does Debian miss that you need for your servers (I am really interested). Also for quick and dirty you could use checkinstall. There is also a good tutorial on DigitalOcean about fpm: https://www.digitalocean.com/community/tutorials/how-to-use-fpm-to-easily-create-packages-in-multiple-formats https://www.digitalocean.com/community/tutorials/how-to-use-... And just maybe me nitpicking too much but the title should be then "How to quickly create deb package for personal needs". Notice that this means you don't get Debian Security support for your own package so that can be a huge breaker for many people running servers :)
    - ssundarraj 11y ago
      I wasn't aware of the DigitalOcean tutorials and the tutorials on debian.org (at least the ones I saw) were pretty dense. I wanted to just package it up and get it running within a few hours (quick dirty install as you said) and couldn't use anything else due to external constraints. I agree with the modified title suggestion and have changed the title of my blog post. Thanks for your feedback! :)
      - zlatan_todoric 11y ago
        You welcome and thanks for taking suggestions into account. For simple things you probably want to use in future more of checkinstall (to keep it easier for yourself the creation, installation and removal part): https://wiki.debian.org/CheckInstall https://wiki.debian.org/CheckInstall
        ssundarraj 11y ago
        CheckInstall looks nice! I'll definitely take it into account next time I need a quick package done. I've also added it to my post. Thanks!
- scrollaway 11y ago
  I don't mean to stir up trouble so don't take my comment offensively or anything - but every time I see debian packaging being talked about reminds me how thankful I should be to only have to deal with Arch packages. The Debian packaging pipeline is really insanely complex. Arch packaging barely needs a tutorial at all. The best part about it is how all the packaging tools are shipped with the package manager. pacman can install remote packages as well as tarballs, and "makepkg" ships with pacman. Scratch that actually - the best part about it is how development libraries ship alongside the packages. I really don't miss having to install -dev packages all the time, especially having hundreds of them polluting all my queries. When I tried creating packages for debian (this was quite a way back and it seems like things have improved, but not that much), I spent ages getting all the packages I needed in the first place and I had to keep track of far too many commands, had to constantly re-open the tutorials every time I wanted to create a new one. The PPA system is also far too cumbersome for one-off packages you want to distribute, compared to distributing just a PKGBUILD / source package (especially since arch has the AUR). I feel the debian world could really stand to take some lessons from Arch in that aspect.
  - zlatan_todoric 11y ago
    There is a big difference in quality of packages. Debian primary focus is stability, security, upgrading from 5 years old package to newest, strict freedom. You can build Debian packages as Arch but that wouldn't be the Debian way. Stability - our QA process is huge and much more strict then the Arch one. We often notice upstream bugs during our packaging and testing process and we also often patch them before upstream. Security - we have Debian Security Team which is ruthless and security is a big focus so when for example the Chromium security problems was found, it was also noticed that that feature was disabled in Debian chromium package by default. Upgrading - I don't think any distro can offer this without issues and those issues are exactly prevented with out packaging guides and Debian Policy. In Arch you would get from time to time - please do this manual things in order to upgrade to next version of this software. While in Debian you can go to trip to Mars, live there for few years, come back and then just apt update && apt dist-upgrade the thing and go on coffee without worry. Also notice we had much before Arch the gpg signing of packages, you can't become Debian maintainer without at least two Debian Developer signatures on your key which happen in face-to-face meetings (so we create a web of trust you will not introduce bad code in your packaging). So yes, you are correct that easier is to create Arch package then Debian official one, but in Debian you can also create very quickly packages (checkinstall, fpm etc etc) but then you miss all the power of Debian and you're on your own with those packages and potential breakage with system (or is that a freedom you have?) :)
robinson-wall 11y ago
> If you’re using OS X you can install it from homebrew (brew install dpkg). While you can build a package of something simple like this example (static html), as soon as you want to compile a binary you're going to need to be building on the same environment as you're targeting. I'd suggest removing any mention of OSX from the guide, or making it clear of the limitations of trying to build debs on it.
- ssundarraj 11y ago
  I've added the limitation of this! Thanks for the feedback. That didn't strike me at all.
zimbatm 11y ago
This is a tutorial for building quick one-off packages that won't ever be accepted by debian but that you can use with your own servers. If you want to do that, you will be better off using Jordan Sissel's fpm tool: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm It can take any project and quickly package it into a .deb, .rpm, .whatever package.
- ssundarraj 11y ago
  Agreed, no doubt. Just a quick start guide for beginner packages.
SFjulie1 11y ago
Having had to rebuild debian/foedora/RH package, this tutorial is lacking all the specifity of debian: bureaucracy, complexity, rigidity and breaking things. If you make a package for openssl, don't forget you are a packager, you know nothing of coding, but please reduce the entropy in the name of security. This tutorial is bad, it demystifies the fact that a package is simply an archive with entry points for code pre/post inst/rm, and that users should be FREE (like in free software) to make their own easily. It is amazing that with an organizational culture debian achieved to void their own manifesto. Microsoft could learn from them. Lived long enough to see the good guys turn into the bad guys.
perlgeek 11y ago
If you use the standard debhelper toolchain instead, you get lots of stuff for free. Want to ship a systemd service file? include "--with systemd" in the dh invocation in debian/rules (and add dh-systemd as a build dependency), and you can drop your system files in debian/yourpackage.service. The helper will do all the work for you like copying the service file to the right location, doing the "daemon-reload" to make sure it is read after it's changed, reload it after package installation, stop if when the package is uninstalled, and so on. Want to create an empty directory? add it to debian/dirs. Want to install additional files? add them to debian/install. Want to create a debian package from an existing perl module? "dh-make-perl --cpan The::Package". And the nice thing is that all of these mechanisms are composable, and it is easy to override steps you want to customize. At first, I found the standard debhelper toolchain to be complex too, but it actually makes simple things easy, and hard things possible. Shameless plug: Yesterday I've blogged about debian packaging a simplistic Perl web application: http://perlgeek.de/blog-en/automating-deployments/2016-005-example-project.html http://perlgeek.de/blog-en/automating-deployments/2016-005-e... (not much Perl specific in there).

44 points by ssundarraj 11y ago

Being a Debian maintainer, that is a very bad and low quality tutorial. You missed a lot of files in debian directory, even your example of control file is not good enough, you're using practices to build package which would reject your package from even entering Debian. Also lintian is a must be if you work with Debian (and it would really scream with your tutorial). Better tutorials: https://wiki.debian.org/IntroDebianPackaging https://wiki.debian.org/IntroDebianPackaging https://wiki.debian.org/HowToPackageForDebian https://wiki.debian.org/HowToPackageForDebian https://people.debian.org/~osamu/maint-guide.html https://people.debian.org/~osamu/maint-guide.html https://wiki.debian.org/PackagingWithGit https://wiki.debian.org/PackagingWithGit (because we are all going to git the world).

rahiel 11y ago
If on the other hand your goal is not to get a package in Debian, but only to quickly make a deb file, check out fpm: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm.
- zlatan_todoric 11y ago
  Yep, the tutorial name should be how to quickly (low quality) create a deb package from simple source. :) Also you can use equivs for creating quick (dummy?) packages :D
  - brudgers 11y ago
    The link to other resources and the expertise expressed in the head comment of this thread was helpful. The insults are not.
    - zlatan_todoric 11y ago
      what insults?
regularfry 11y ago
As a Debian user, it's a fine tutorial. Not every .deb is built for distribution with Debian itself. The only change I'd make is to clarify that what's being built here is a "for personal use only" package. As to the debian.org guides, I've always found them obtuse precisely because they emphasise what you've got to do to get a package distributed, rather than the plain technical details of how they work.
- zlatan_todoric 11y ago
  Packaging tutorial shouldn't be technical details how deb package works but how you build one (if you want those details you can also find them in Debian documentation but in the end deb package is just an ar file with it's set of make file that satisfies the installation in specific distro - this is the simple explanation). And no, the tutorial is misleading because Debian packaging means doing it for Debian, while creating a deb package for your personal need is different. You also have Ubuntu packaging guides and so on.
  - regularfry 11y ago
    But the guides aren't just how you build a package. They're how you package something for official distribution. The requirements for the former aren't nearly as stringent as for the latter, and by obscuring the former behind the latter, Debian makes its packaging guides less useful.
    - zlatan_todoric 11y ago
      Debian packaging guides are less useful because they concentrate on how to build package for Debian? And nobody is hiding from you any tutorial - Debian is an open community and the wiki is open to everyone so you can search for what you need but I really don't see the point in your sentences (are you saying that we should favorite somehow quick and dirty hacks instead of our strict high-quality ways of building packages? Because if yes, then Debian wouldn't be what it is today...)
      - 11y ago
ssundarraj 11y ago
Those are definitely better links, but a while back I needed a quick guide to make something that worked on private servers. I couldn't find a quickstart guide, so I decided to make one. Thanks for the feedback!
- zlatan_todoric 11y ago
  You really should take more care of servers :) What does Debian miss that you need for your servers (I am really interested). Also for quick and dirty you could use checkinstall. There is also a good tutorial on DigitalOcean about fpm: https://www.digitalocean.com/community/tutorials/how-to-use-fpm-to-easily-create-packages-in-multiple-formats https://www.digitalocean.com/community/tutorials/how-to-use-... And just maybe me nitpicking too much but the title should be then "How to quickly create deb package for personal needs". Notice that this means you don't get Debian Security support for your own package so that can be a huge breaker for many people running servers :)
  - ssundarraj 11y ago
    I wasn't aware of the DigitalOcean tutorials and the tutorials on debian.org (at least the ones I saw) were pretty dense. I wanted to just package it up and get it running within a few hours (quick dirty install as you said) and couldn't use anything else due to external constraints. I agree with the modified title suggestion and have changed the title of my blog post. Thanks for your feedback! :)
    - zlatan_todoric 11y ago
      You welcome and thanks for taking suggestions into account. For simple things you probably want to use in future more of checkinstall (to keep it easier for yourself the creation, installation and removal part): https://wiki.debian.org/CheckInstall https://wiki.debian.org/CheckInstall
      - ssundarraj 11y ago
        CheckInstall looks nice! I'll definitely take it into account next time I need a quick package done. I've also added it to my post. Thanks!
scrollaway 11y ago
I don't mean to stir up trouble so don't take my comment offensively or anything - but every time I see debian packaging being talked about reminds me how thankful I should be to only have to deal with Arch packages. The Debian packaging pipeline is really insanely complex. Arch packaging barely needs a tutorial at all. The best part about it is how all the packaging tools are shipped with the package manager. pacman can install remote packages as well as tarballs, and "makepkg" ships with pacman. Scratch that actually - the best part about it is how development libraries ship alongside the packages. I really don't miss having to install -dev packages all the time, especially having hundreds of them polluting all my queries. When I tried creating packages for debian (this was quite a way back and it seems like things have improved, but not that much), I spent ages getting all the packages I needed in the first place and I had to keep track of far too many commands, had to constantly re-open the tutorials every time I wanted to create a new one. The PPA system is also far too cumbersome for one-off packages you want to distribute, compared to distributing just a PKGBUILD / source package (especially since arch has the AUR). I feel the debian world could really stand to take some lessons from Arch in that aspect.
- zlatan_todoric 11y ago
  There is a big difference in quality of packages. Debian primary focus is stability, security, upgrading from 5 years old package to newest, strict freedom. You can build Debian packages as Arch but that wouldn't be the Debian way. Stability - our QA process is huge and much more strict then the Arch one. We often notice upstream bugs during our packaging and testing process and we also often patch them before upstream. Security - we have Debian Security Team which is ruthless and security is a big focus so when for example the Chromium security problems was found, it was also noticed that that feature was disabled in Debian chromium package by default. Upgrading - I don't think any distro can offer this without issues and those issues are exactly prevented with out packaging guides and Debian Policy. In Arch you would get from time to time - please do this manual things in order to upgrade to next version of this software. While in Debian you can go to trip to Mars, live there for few years, come back and then just apt update && apt dist-upgrade the thing and go on coffee without worry. Also notice we had much before Arch the gpg signing of packages, you can't become Debian maintainer without at least two Debian Developer signatures on your key which happen in face-to-face meetings (so we create a web of trust you will not introduce bad code in your packaging). So yes, you are correct that easier is to create Arch package then Debian official one, but in Debian you can also create very quickly packages (checkinstall, fpm etc etc) but then you miss all the power of Debian and you're on your own with those packages and potential breakage with system (or is that a freedom you have?) :)

robinson-wall 11y ago

> If you’re using OS X you can install it from homebrew (brew install dpkg). While you can build a package of something simple like this example (static html), as soon as you want to compile a binary you're going to need to be building on the same environment as you're targeting. I'd suggest removing any mention of OSX from the guide, or making it clear of the limitations of trying to build debs on it.

ssundarraj 11y ago
I've added the limitation of this! Thanks for the feedback. That didn't strike me at all.

zimbatm 11y ago

This is a tutorial for building quick one-off packages that won't ever be accepted by debian but that you can use with your own servers. If you want to do that, you will be better off using Jordan Sissel's fpm tool: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm It can take any project and quickly package it into a .deb, .rpm, .whatever package.

ssundarraj 11y ago
Agreed, no doubt. Just a quick start guide for beginner packages.

SFjulie1 11y ago

Having had to rebuild debian/foedora/RH package, this tutorial is lacking all the specifity of debian: bureaucracy, complexity, rigidity and breaking things. If you make a package for openssl, don't forget you are a packager, you know nothing of coding, but please reduce the entropy in the name of security. This tutorial is bad, it demystifies the fact that a package is simply an archive with entry points for code pre/post inst/rm, and that users should be FREE (like in free software) to make their own easily. It is amazing that with an organizational culture debian achieved to void their own manifesto. Microsoft could learn from them. Lived long enough to see the good guys turn into the bad guys.

perlgeek 11y ago

If you use the standard debhelper toolchain instead, you get lots of stuff for free. Want to ship a systemd service file? include "--with systemd" in the dh invocation in debian/rules (and add dh-systemd as a build dependency), and you can drop your system files in debian/yourpackage.service. The helper will do all the work for you like copying the service file to the right location, doing the "daemon-reload" to make sure it is read after it's changed, reload it after package installation, stop if when the package is uninstalled, and so on. Want to create an empty directory? add it to debian/dirs. Want to install additional files? add them to debian/install. Want to create a debian package from an existing perl module? "dh-make-perl --cpan The::Package". And the nice thing is that all of these mechanisms are composable, and it is easy to override steps you want to customize. At first, I found the standard debhelper toolchain to be complex too, but it actually makes simple things easy, and hard things possible. Shameless plug: Yesterday I've blogged about debian packaging a simplistic Perl web application: http://perlgeek.de/blog-en/automating-deployments/2016-005-example-project.html http://perlgeek.de/blog-en/automating-deployments/2016-005-e... (not much Perl specific in there).