4 ms·

How to build a Debian package

120 points by eloycoto 12y ago

giancarlostoro 12y ago
My one question: does all of this apply to Ubuntu as well? or most of it, and if not why not? I would assume (bad to do so) it should work, only issues would be you would want to package each project independently on it's respective platform / OS version.
- billyboar 12y ago
  I guess it should work on all linux systems that use dpkg package management system.
- _delirium 12y ago
  Yes, many Ubuntu packages even come directly from Debian as the Ubuntu upstream. So building Ubuntu packages is very similar. In fact the preferred route is to get the package included in Debian first, and then Ubuntu will just pick it up as a downstream (some packages do go directly into Ubuntu for various reasons).
  - giancarlostoro 12y ago
    Great feedback, I'm definitely bookmarking this page, and probably archiving it then.
cowmix 12y ago
fpm or: How I Learned to Stop Worrying and Love Linux Package Management https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
- jvehent 12y ago
  Most definitely. I use it for building RPM, DEBs and even MacOS PKGs and it works great. https://github.com/mozilla/mig/blob/master/Makefile#L233-L272 https://github.com/mozilla/mig/blob/master/Makefile#L233-L27... Package signing could use some love, but it's still doable easily with a few extra steps.
  - baldfat 12y ago
    I can't say this enough. The most underused tool in OpenSource community. https://build.opensuse.org/ https://build.opensuse.org/ Quote: The openSUSE Build Service is the public instance of the Open Build Service (OBS) used for development of the openSUSE distribution and to offer packages from same source for Fedora, Debian, Ubuntu, SUSE Linux Enterprise and other distributions..
chriswarbo 12y ago
This guide looks quite nice; there are certainly tools I've not used before. One thing that's good about Debian packages (and I'm sure many other formats): it's really easy to get something that works; everything else is optional extras. For example (if I remember correctly; I've not used Debian for a while): # Set up directory structure: mkdir -p my_package/DEBIAN mkdir -p my_package/usr/bin # Copy in the files you want the package to contain cp my_binary my_package/usr/bin/ # Add metadata echo "2" > my_package/DEBIAN/version # Write skeletal my_package/DEBIAN/control here # Build, install and use dpkg -b my_package dpkg -i my_package*.deb my_binary Of course, such a package is never going to be accepted into Debian's repos, but that's not the point: it makes it less likely to say "screw it, I'll dump stuff into /opt manually". There's also the excellent "checkinstall" program, which does a pretty good job of turning autoconf-style source repos into decent packages. With any of these approaches, the package manager keeps track of the files so they can all be removed in the future (just don't write crazy destructive pre/post scripts!).
xai3luGi 12y ago
The official documentation: http://mentors.debian.net/intro-maintainers http://mentors.debian.net/intro-maintainers
mike-cardwell 12y ago
I find dh-make-perl quite useful. Lets you build Debian packages from Perl modules: apt-get install dh-make-perl dh-make-perl --cpan Some::Module cd into the directory the above made debuild Now you have a .deb of Some::Module.
- jordigh 12y ago
  In a similar vein, I use pypi-install to directly grab Python packages as Debian packages.
IgorPartola 12y ago
Here's my own version: https://igorpartola.com/debianization/ https://igorpartola.com/debianization/. It tells you how to set up your own repo as well. Edit: I should add that I love me some Debian packages. At my previous $JOB, I converted the monolithic codebase we had into roughly 50 Debian packages and deployed it from our own package repo. I set up Puppet on top of this to deploy changes to the servers. The biggest upside of this was that we had to write no custom code to manage dependencies, etc. The old broken shell deploy script went away, and we were able to move from SVN to git without having to update much (except how we generated debian/changelog). The biggest PITA when I was doing packaging was writing proper init scripts. If the daemon is run with an interpreter (#!/usr/bin/python), you have to update the part of the init script that checks if the process is running. Also, compiling .py to .pyc files gave me some trouble, though that has now been greatly improved.
pbhjpbhj 12y ago
I used to use checkinstall on Slackware to make packages, you'd do "./configure; make; checkinstall" and it made you a package to install with the system tools. It did deb packages and rpm too IIRC. https://wiki.debian.org/CheckInstall https://wiki.debian.org/CheckInstall
amyjess 12y ago
At my last company, I built debs for our software (which was only distributed on our hardware, and customers didn't interact at the system level at all), and I just wrote a shell script to make them manually. Just take your data and control directories and the debian-binary file, and wrap them up in an ar archive. You'll have to learn how to write a control file by hand, but that's easy. The cool thing is that building the packages manually is distro-agnostic. No need for a VM or anything. Most of our stuff was in Java or Python, so even though our hardware ran Ubuntu, I'd develop and build the packages on my Arch machine before pushing to the device for testing. We eventually automated things some more, storing the data and control directories in SVN, with a simple GUI running on the device (we did not distribute this tool to customers) to pull down a package from SVN, build it, and install it on the device, using something based on the SVN revision number as the package version. That led to a pretty good workflow. We'd make a change, commit it into the dev branch of our packages repo, then go over to the device and push a button to pull it down.
regularfry 12y ago
I've written something for deploying ruby apps here: http://github.com/BytemarkHosting/au http://github.com/BytemarkHosting/au It uses bundler locally to wrap all your dependencies into a single package, so you don't have to care about packaging each individual gem, and supplies an `activate` script like Python's virtualenv. Something else it does, which I've not seen elsewhere, is scan your binary gems for library dependencies, so you get all the deps (say, libxml and libxslt) installed when you apt-get install your app's package. This works really well for me.
ddispaltro 12y ago
Related but I've found this[1] to work really well for jvm based packaging. [1] https://github.com/sbt/sbt-native-packager https://github.com/sbt/sbt-native-packager

120 points by eloycoto 12y ago

My one question: does all of this apply to Ubuntu as well? or most of it, and if not why not? I would assume (bad to do so) it should work, only issues would be you would want to package each project independently on it's respective platform / OS version.

billyboar 12y ago
I guess it should work on all linux systems that use dpkg package management system.
_delirium 12y ago
Yes, many Ubuntu packages even come directly from Debian as the Ubuntu upstream. So building Ubuntu packages is very similar. In fact the preferred route is to get the package included in Debian first, and then Ubuntu will just pick it up as a downstream (some packages do go directly into Ubuntu for various reasons).
- giancarlostoro 12y ago
  Great feedback, I'm definitely bookmarking this page, and probably archiving it then.

cowmix 12y ago

fpm or: How I Learned to Stop Worrying and Love Linux Package Management https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm

jvehent 12y ago
Most definitely. I use it for building RPM, DEBs and even MacOS PKGs and it works great. https://github.com/mozilla/mig/blob/master/Makefile#L233-L272 https://github.com/mozilla/mig/blob/master/Makefile#L233-L27... Package signing could use some love, but it's still doable easily with a few extra steps.
- baldfat 12y ago
  I can't say this enough. The most underused tool in OpenSource community. https://build.opensuse.org/ https://build.opensuse.org/ Quote: The openSUSE Build Service is the public instance of the Open Build Service (OBS) used for development of the openSUSE distribution and to offer packages from same source for Fedora, Debian, Ubuntu, SUSE Linux Enterprise and other distributions..

chriswarbo 12y ago

This guide looks quite nice; there are certainly tools I've not used before. One thing that's good about Debian packages (and I'm sure many other formats): it's really easy to get something that works; everything else is optional extras. For example (if I remember correctly; I've not used Debian for a while): # Set up directory structure: mkdir -p my_package/DEBIAN mkdir -p my_package/usr/bin # Copy in the files you want the package to contain cp my_binary my_package/usr/bin/ # Add metadata echo "2" > my_package/DEBIAN/version # Write skeletal my_package/DEBIAN/control here # Build, install and use dpkg -b my_package dpkg -i my_package*.deb my_binary Of course, such a package is never going to be accepted into Debian's repos, but that's not the point: it makes it less likely to say "screw it, I'll dump stuff into /opt manually". There's also the excellent "checkinstall" program, which does a pretty good job of turning autoconf-style source repos into decent packages. With any of these approaches, the package manager keeps track of the files so they can all be removed in the future (just don't write crazy destructive pre/post scripts!).

xai3luGi 12y ago

The official documentation: http://mentors.debian.net/intro-maintainers http://mentors.debian.net/intro-maintainers

mike-cardwell 12y ago

I find dh-make-perl quite useful. Lets you build Debian packages from Perl modules: apt-get install dh-make-perl dh-make-perl --cpan Some::Module cd into the directory the above made debuild Now you have a .deb of Some::Module.

jordigh 12y ago
In a similar vein, I use pypi-install to directly grab Python packages as Debian packages.

IgorPartola 12y ago

Here's my own version: https://igorpartola.com/debianization/ https://igorpartola.com/debianization/. It tells you how to set up your own repo as well. Edit: I should add that I love me some Debian packages. At my previous $JOB, I converted the monolithic codebase we had into roughly 50 Debian packages and deployed it from our own package repo. I set up Puppet on top of this to deploy changes to the servers. The biggest upside of this was that we had to write no custom code to manage dependencies, etc. The old broken shell deploy script went away, and we were able to move from SVN to git without having to update much (except how we generated debian/changelog). The biggest PITA when I was doing packaging was writing proper init scripts. If the daemon is run with an interpreter (#!/usr/bin/python), you have to update the part of the init script that checks if the process is running. Also, compiling .py to .pyc files gave me some trouble, though that has now been greatly improved.

pbhjpbhj 12y ago

I used to use checkinstall on Slackware to make packages, you'd do "./configure; make; checkinstall" and it made you a package to install with the system tools. It did deb packages and rpm too IIRC. https://wiki.debian.org/CheckInstall https://wiki.debian.org/CheckInstall

amyjess 12y ago

At my last company, I built debs for our software (which was only distributed on our hardware, and customers didn't interact at the system level at all), and I just wrote a shell script to make them manually. Just take your data and control directories and the debian-binary file, and wrap them up in an ar archive. You'll have to learn how to write a control file by hand, but that's easy. The cool thing is that building the packages manually is distro-agnostic. No need for a VM or anything. Most of our stuff was in Java or Python, so even though our hardware ran Ubuntu, I'd develop and build the packages on my Arch machine before pushing to the device for testing. We eventually automated things some more, storing the data and control directories in SVN, with a simple GUI running on the device (we did not distribute this tool to customers) to pull down a package from SVN, build it, and install it on the device, using something based on the SVN revision number as the package version. That led to a pretty good workflow. We'd make a change, commit it into the dev branch of our packages repo, then go over to the device and push a button to pull it down.

regularfry 12y ago

I've written something for deploying ruby apps here: http://github.com/BytemarkHosting/au http://github.com/BytemarkHosting/au It uses bundler locally to wrap all your dependencies into a single package, so you don't have to care about packaging each individual gem, and supplies an `activate` script like Python's virtualenv. Something else it does, which I've not seen elsewhere, is scan your binary gems for library dependencies, so you get all the deps (say, libxml and libxslt) installed when you apt-get install your app's package. This works really well for me.

ddispaltro 12y ago

Related but I've found this[1] to work really well for jvm based packaging. [1] https://github.com/sbt/sbt-native-packager https://github.com/sbt/sbt-native-packager