* creating Debian packages is a difficult process to learn. There’s a bunch of tools and wrappers around those tools to handle inadequacies and it’s not clear how to do it “right”. For example, if I just have a binary and want to put it into a Debian package without pulling in some random shell scripts that aren’t part of Debian proper, it’s not immediately clear how to do that.
* Non-atomic and imperative install/remove/etc. hooks make it difficult to robustly handle failures. Since there is no file system manifest or sandboxing, there’s no real guarantees that removing a package will actually remove it.
* there’s no spec for a .deb package. This means the only way to correctly generate a Debian package is through the difficult tooling. I understand why this choice is made, and it has a lot of benefits for the continued evolution of the debian project. However, it makes it difficult to build better tooling around deb packages.
If you "just have a binary" then you aren't compiling from source, which means you can't make modifications to that binary easily, which Debian wants to be able to do to fix security issues and other bugs.
There is a large range of documentation, everything from the simple to the more advanced to different packaging niches. The large amount of docs makes that harder to navigate though, and a lot of stuff is moving towards automated packaging these days anyway.
Having to use these automatic packaging tools is exactly my gripe. I don’t want to have to rely on whatever scripts someone conjured up if it’s not supported by the distro itself.
I agree it always makes sense to have sources involved for packages that are getting distributed as part of the distro, but what if I want to just deploy my product on a server without the sources?
The tools I am talking about are integrated into, supported by, and used by packages within, the distro itself. I'm not talking about external things that make low quality packages.
If you want to make external packages (such as those that don't come with source), then you can just use `dpkg-deb --build` or one of its many wrappers to shove the binary into a .deb.
I can’t find it right now, but the Debian docs explicitly indicate that you shouldn’t do that because the internal format is not stable. It has changed significantly in the past, and the only “supported” way to do it is with the official Debian tools
The .deb format doesn't change significantly at all, the only changes in recent years have been changes to default compression choices (old ones are retained forever though) and some additional fields in the control file.
The only significant future change I can think of is the mtree stuff, which would add an additional metadata file to .deb files.
There are several warts in the .deb file format that the dpkg folks aren't fixing because of compatibility concerns.
* creating Debian packages is a difficult process to learn. There’s a bunch of tools and wrappers around those tools to handle inadequacies and it’s not clear how to do it “right”. For example, if I just have a binary and want to put it into a Debian package without pulling in some random shell scripts that aren’t part of Debian proper, it’s not immediately clear how to do that.
* Non-atomic and imperative install/remove/etc. hooks make it difficult to robustly handle failures. Since there is no file system manifest or sandboxing, there’s no real guarantees that removing a package will actually remove it.
* there’s no spec for a .deb package. This means the only way to correctly generate a Debian package is through the difficult tooling. I understand why this choice is made, and it has a lot of benefits for the continued evolution of the debian project. However, it makes it difficult to build better tooling around deb packages.