4 ms·

HEADLINE: Easier way to create local packages DESCRIPTION: My first distro was Debian. Then, for a while, I used Arch. But it kept irritating me with its total

HEADLINE: Easier way to create local packages DESCRIPTION: My first distro was Debian. Then, for a while, I used Arch. But it kept irritating me with its total disregard for backwards-compatibility (symlinking /usr/bin/python to python3), coarse-grained packages (want to install QEMU PPC without pulling in every other architecture as well? too bad!), lack of debug packages (good luck rebuilding WebKit just to get stack traces after a SIGSEGV), and package versioning ignoring ABI incompatibilities (I once managed to disable the package manager by upgrading it without also upgrading its dependencies... and later cut off WiFi in a similar manner). So, when I finally trashed my root partition a few weeks ago, I decided to use the opportunity to return to Debian. One thing I miss from Arch, though, is having an easy way to create a package. It's simply a matter of reading one manpage, writing a shellscript with package metadata in variables and two-to-four functions (to patch up the unpacked source, check the version, build it, and finally create a tarball), and then running `makepkg`. And it will just download the source code, check signatures, patch it, and build it in one step; it even supports downloading and building packages straight from the development repository. I took advantage of it to create locally-patched versions of some software I use, while keeping it up to date and still under the package manager's control. Contrast that with creating a .deb, where doing the equivalent seems to require invoking several different utilities (uscan, dch, debuild; though ) and keeping track of separate files like debian/control, debian/changelog, debian/rules and whatever else. All the tooling around building packages seems oriented towards distro maintainers rather than users. I'd love something that would relieve me of at least some of the burden of creating a local package from scratch. DISTRIBUTION: unstable, I guess

falcolas 9y ago
I will +1 this. I generally end up copying a bunch of the required control files from another project and using a higher level script which creates the deb for me via black magic. I would love to understand the process more, but the depth of knowledge required to grok the process from end-to-end is well beyond the time I can commit to it. On a related note, the way that repos can only be secured as a whole (and require each package to effectively be present when creating the signature) makes adding a single authenticated package to an existing repo much harder than it needs to be.
whbboyd 9y ago
Look into the equivs package: https://packages.debian.org/stretch/equivs https://packages.debian.org/stretch/equivs. It's intended mostly for making metapackages, but you can include files as well.
- zeotroph 9y ago
  This (and checkinstall) are stopgaps, ideally the .deb creation process would get an entirely new packaging toolchain, with the minimal arguments: dependencies, build-dependencies, sourcefile/url/repo, buildcommands. Then a linter could tell you that a changelog.Debian.gz, man-pages and debtags are still missing, but for internal redistribution that is enough for now. And can failed build commands continue from where they were interrupted? Always cleaning everything is terrible for iterative exploration of the package creation process. The final package should be marked as tainted of course, but always starting a minute long compile process should be skippable.
wbkang 9y ago
How about checkinstall for making a quick and dirty package? :P
- aleden 9y ago
  I've had very bad experience with checkinstall. The idea seems perfectly sound, but the implementation needs a lot of work. The UI needs to be better (e.g. saving your answers to the questions about title, author, etc.) And there are also some straight up bugs. It has crashed for me many times. And not even for a sketchy program- I'm talking like llvm.
SteveNuts 9y ago
I always use FPM https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
mixmastamyk 9y ago
Maybe snaps can fill this role, I understand they are easier to create.
- popey 9y ago
  They're certainly easier to create than debs. For many applications a single yaml file is all that's needed. Snapcraft can use whatever build system the app needs, and produce a snap which can be locally installed, shared privately or more widely via the snap store. I made a short video about it. https://www.youtube.com/watch?v=DLxqdf89hRo https://www.youtube.com/watch?v=DLxqdf89hRo
majewsky 9y ago
If you just want to pack up a bunch of config files, I can shamelessly plug my own https://github.com/holocm/holo-build https://github.com/holocm/holo-build
izacus 9y ago
Hmm, I usually use checkinstall for that and it worked rather decently for building quick-and-dirty .DEB packages used locally. Did you try it yet?
CJefferson 9y ago
Really +1. There are some programs I work on that I wanted to package for debian, but after a full day of no progress I gave up and threw my hands in the air.
shadeslayer 9y ago
Re Easier way to create local packages, you can use dh-make[1] to populate the packaging with some templates that might make your job a bit easier :) [1] https://packages.debian.org/en/sid/dh-make https://packages.debian.org/en/sid/dh-make
vbernat 9y ago
Creating your own packages with Debian tools is easier now than ever. Unfortunately, the documentation may be lagging a bit and will also focus of making state-of-the-art packages. Last year, I have written some examples on how to do simple packages while still leveraging Debian tools: https://vincent.bernat.im/en/blog/2016-pragmatic-debian-packaging https://vincent.bernat.im/en/blog/2016-pragmatic-debian-pack... Also, automatic package generation for many languages already providing package management (Python, Ruby, Java, Go, ...) is already a reality but you have a different tool for each. The topic comes back regularly but until now, we don't have a generic tool for that. The last attempt was debdry but it isn't maintained anymore.
- Corrado 9y ago
  Yes, I think documentation is part of the problem. When I was a heavy Debian user several years ago I tried to create my own packages but failed. The problem was that the documentation was too numerous to find anything, especially the current way to build packages. Every single resource I tried had 2-3 different ways to build packages and it was difficult|impossible to tell which one was the "recommended" way. I ended up not creating any packages and moving on to another distro. :(
- wazoox 9y ago
  Jeebus, my old chap from the old times of fr.comp.os.linux.* actually lurks HN, my that brings memories back :) Sorry for this completely irrelevant interruption :)
- atemerev 9y ago
  If there is no documentation, the feature doesn't exist. If the documentation is misleading or outdated, it's even worse — like a productivity sabotage, stealing many work hours from your fellow developers (looking at you, Docker). I understand that expecting something from free and open source software beyond bare necessities can sound like being entitled. And yet, I believe that documentation is not optional. Software with better documentation wins. All the time.
evand 9y ago
All the learning and process needed to create Debian packages has been a big motivator for us to make snap packaging simple and quick. Have a look at the Heroku CLI snap, for example: https://github.com/heroku/cli/blob/master/snap/snapcraft.yaml https://github.com/heroku/cli/blob/master/snap/snapcraft.yam... You can quickly piece together a snapcraft.yaml, push it to GitHub, and turn on auto builds and publication (https://build.snapcraft.io https://build.snapcraft.io). Then anyone can install your package with a single command - no PPA/repo needed.

falcolas 9y ago

I will +1 this. I generally end up copying a bunch of the required control files from another project and using a higher level script which creates the deb for me via black magic. I would love to understand the process more, but the depth of knowledge required to grok the process from end-to-end is well beyond the time I can commit to it. On a related note, the way that repos can only be secured as a whole (and require each package to effectively be present when creating the signature) makes adding a single authenticated package to an existing repo much harder than it needs to be.

whbboyd 9y ago

Look into the equivs package: https://packages.debian.org/stretch/equivs https://packages.debian.org/stretch/equivs. It's intended mostly for making metapackages, but you can include files as well.

zeotroph 9y ago
This (and checkinstall) are stopgaps, ideally the .deb creation process would get an entirely new packaging toolchain, with the minimal arguments: dependencies, build-dependencies, sourcefile/url/repo, buildcommands. Then a linter could tell you that a changelog.Debian.gz, man-pages and debtags are still missing, but for internal redistribution that is enough for now. And can failed build commands continue from where they were interrupted? Always cleaning everything is terrible for iterative exploration of the package creation process. The final package should be marked as tainted of course, but always starting a minute long compile process should be skippable.

wbkang 9y ago

How about checkinstall for making a quick and dirty package? :P

aleden 9y ago
I've had very bad experience with checkinstall. The idea seems perfectly sound, but the implementation needs a lot of work. The UI needs to be better (e.g. saving your answers to the questions about title, author, etc.) And there are also some straight up bugs. It has crashed for me many times. And not even for a sketchy program- I'm talking like llvm.

SteveNuts 9y ago

I always use FPM https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm

mixmastamyk 9y ago

Maybe snaps can fill this role, I understand they are easier to create.

popey 9y ago
They're certainly easier to create than debs. For many applications a single yaml file is all that's needed. Snapcraft can use whatever build system the app needs, and produce a snap which can be locally installed, shared privately or more widely via the snap store. I made a short video about it. https://www.youtube.com/watch?v=DLxqdf89hRo https://www.youtube.com/watch?v=DLxqdf89hRo

majewsky 9y ago

If you just want to pack up a bunch of config files, I can shamelessly plug my own https://github.com/holocm/holo-build https://github.com/holocm/holo-build

izacus 9y ago

Hmm, I usually use checkinstall for that and it worked rather decently for building quick-and-dirty .DEB packages used locally. Did you try it yet?

CJefferson 9y ago

Really +1. There are some programs I work on that I wanted to package for debian, but after a full day of no progress I gave up and threw my hands in the air.

shadeslayer 9y ago

Re Easier way to create local packages, you can use dh-make[1] to populate the packaging with some templates that might make your job a bit easier :) [1] https://packages.debian.org/en/sid/dh-make https://packages.debian.org/en/sid/dh-make

vbernat 9y ago

Creating your own packages with Debian tools is easier now than ever. Unfortunately, the documentation may be lagging a bit and will also focus of making state-of-the-art packages. Last year, I have written some examples on how to do simple packages while still leveraging Debian tools: https://vincent.bernat.im/en/blog/2016-pragmatic-debian-packaging https://vincent.bernat.im/en/blog/2016-pragmatic-debian-pack... Also, automatic package generation for many languages already providing package management (Python, Ruby, Java, Go, ...) is already a reality but you have a different tool for each. The topic comes back regularly but until now, we don't have a generic tool for that. The last attempt was debdry but it isn't maintained anymore.

Corrado 9y ago
Yes, I think documentation is part of the problem. When I was a heavy Debian user several years ago I tried to create my own packages but failed. The problem was that the documentation was too numerous to find anything, especially the current way to build packages. Every single resource I tried had 2-3 different ways to build packages and it was difficult|impossible to tell which one was the "recommended" way. I ended up not creating any packages and moving on to another distro. :(
wazoox 9y ago
Jeebus, my old chap from the old times of fr.comp.os.linux.* actually lurks HN, my that brings memories back :) Sorry for this completely irrelevant interruption :)
atemerev 9y ago
If there is no documentation, the feature doesn't exist. If the documentation is misleading or outdated, it's even worse — like a productivity sabotage, stealing many work hours from your fellow developers (looking at you, Docker). I understand that expecting something from free and open source software beyond bare necessities can sound like being entitled. And yet, I believe that documentation is not optional. Software with better documentation wins. All the time.

evand 9y ago

All the learning and process needed to create Debian packages has been a big motivator for us to make snap packaging simple and quick. Have a look at the Heroku CLI snap, for example: https://github.com/heroku/cli/blob/master/snap/snapcraft.yaml https://github.com/heroku/cli/blob/master/snap/snapcraft.yam... You can quickly piece together a snapcraft.yaml, push it to GitHub, and turn on auto builds and publication (https://build.snapcraft.io https://build.snapcraft.io). Then anyone can install your package with a single command - no PPA/repo needed.