Comment by pwdisswordfish | Hacker News Reader

Comment by pwdisswordfish | Hacker News Reader

Parent Full thread

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

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.

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-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.

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. :(

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.

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 :)

I always use FPM

https://github.com/jordansissel/fpm

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.yam...

You can quickly piece together a snapcraft.yaml, push it to GitHub, and turn on auto builds and publication (https://build.snapcraft.io). Then anyone can install your package with a single command - no PPA/repo needed.

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

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

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

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.

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

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

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.

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?

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

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.

Reply on news.ycombinator.com