Isn't this overly complicated for what amounts to what could be a single file with 7 lines of information, instead of 3-5 tar archives that contain a single file with 1-3 lines of information?
but still, that was a pretty interesting write up.
I suspect it only looks like overkill in the context of the simplest possible example.
Once you start adding things like pre-inst, post-inst scripts, binary redirections with update-alternatives, I suspect the complications start to pay off.
I wouldn’t agree that it’s overly complicated. Compare it to the Docker/OCI container format with multiple layers of tarballs and complicated manifest.json files. The deb format appears much simpler.
it's 3 files, 1 file that really just specified deb format version and 2 tar files. data.tar.gz (extracted out to file system) and control.tar.gz (a set of metadata file, including installation scripts).
Yeah, Debian is very, very unergonomic for package maintainers. I get that it's historically groen, but it has historically grown into an abomination that scares off people.
Arch packaging is a breeze in comparison. You indeed only need one file and that's it.
Well, to be fair, no package maintainers are touching any of the stuff described here. All the "ar" and "control.tar" stuff is handled for you by the tools. This isn't a "this is how you build packages" article, it's a "here's how the guts of these packages work" article.
This article is great for understanding the deb format. Lots of tools can make deb archives e.g. https://fpm.readthedocs.io/ . However making a binary package for users is a quite different thing to making a deb suitable for inclusion in Debian itself. A debian source package is a tuple of three .dsc + .tar.gz + .debian.tar.gz files.
I thought a relevant comment on that story by o11c [0] was particularly insightful based on my experience with Debian packaging. The format is probably optimised for long term maintenance or running up against inherent complexity or something (works great as a user) but the process of setting up a package did have a weirdly high-friction feel. The last time I tried to package something for a Debian system it felt a lot more like constructing a fork of the project than distributing something that already existed.
Not OP but I have started with https://github.com/FooBarWidget/debian-packaging-for-the-mod... - it's 4 years old but the basics are still valid. Then I would recommend the debhelper documentation. I maintain a few binary deb packages for my own repo myself. For this I would recommend reprepro.
First try updating an existing source package or adding a patch to one. Hell, just download one with `apt-get source` and just read it— look at the files that make up the source package. Then download a few more. Maybe try and build some. Change a couple files before building and see what happens.
Once you have a feel for that stuff, use debhelper to create a new package 'from scratch' (from an upstream source tarball).
This 'tutorial'¹ presents basically the same info as the Debian packaging docs² but it feels more easily digestible to me because of how it's chopped up into slides.
Some of the manpages are also good. The debhelper manpage³ refers you to other small docs, notably dh_make⁴, which is probably your best starting point for creating a package from scratch.
Readit News
but still, that was a pretty interesting write up.
Once you start adding things like pre-inst, post-inst scripts, binary redirections with update-alternatives, I suspect the complications start to pay off.
In practice, how would one make it simpler?
i'd note it's simplicity (and the fact that ipkg/ipk format was based on it), was what enabled me to help the people who "jailbroke" (really just install homebrew apps) the palm pre: https://www.engadget.com/2009-06-22-pre-apps-successfully-in...
I was able to assist people that had the device without even having one as the format (to me at least) was very simple.
Arch packaging is a breeze in comparison. You indeed only need one file and that's it.
Barely anybody uses Arch outside the HN bubble, it's a blip compared to the amount of Redhat/Debian out there in Enterprise/Web 1.9
This article is great for understanding the deb format. Lots of tools can make deb archives e.g. https://fpm.readthedocs.io/ . However making a binary package for users is a quite different thing to making a deb suitable for inclusion in Debian itself. A debian source package is a tuple of three .dsc + .tar.gz + .debian.tar.gz files.
[0] https://news.ycombinator.com/item?id=41638352
I appreciate first principles, but i just used dkpg-deb --build
Once you have a feel for that stuff, use debhelper to create a new package 'from scratch' (from an upstream source tarball).
This 'tutorial'¹ presents basically the same info as the Debian packaging docs² but it feels more easily digestible to me because of how it's chopped up into slides.
Some of the manpages are also good. The debhelper manpage³ refers you to other small docs, notably dh_make⁴, which is probably your best starting point for creating a package from scratch.
--
1: https://www.debian.org/doc/manuals/packaging-tutorial/packag...
2: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html#...
3: https://manpages.debian.org/bullseye/debhelper/debhelper.7.e...
4: https://manpages.debian.org/testing/dh-make/dh_make.1.en.htm...
Deleted Comment