4 ms·

Glad there is better tooling, but in 5 years, when I'll need it, I'm pretty sure I won't know how to use it. I've had to build a deb package once. It's crazy h

Glad there is better tooling, but in 5 years, when I'll need it, I'm pretty sure I won't know how to use it. I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are. The package format itself is quite complex, and you don't know if you must do something imperatively or decoratively, when to trigger it in the workflow of the install, if it makes sense to use debconf or not, how to use debconf with something else than bash, good practices, where to put things, to copy files, etc. And that's before you have to deal with dependencies. Then you have to repeat that for rpm. No wonder people are attracted to flatpak and snap. Creating a installer for mac, windows and linux is a hell of a work. Not to mention making sure it compiles and run on all those platforms. Sometimes more than coding the program itself.

GuB-42 3y ago
Maybe you want a non deb specific packager. cpack (cmake packager) can generate Windows, OSX, DEB, RPM and simple archives. There is also fpm that doesn't support Windows, but supports plenty of packet managers. And possibly many others. AppImage, FlatPak and Snap may actually be worse in that regard, because they are like other distros you have to take into account. So now, you may have to do all of them: deb, rpm, flatpak, snap, appimage, tgz, whatever that's on Windows and OSX, maybe a Docker container too, app stores and mobile stuff, and upload to some npm, maven, crate.io,... It makes generic package manager even more important.
- BiteCode_dev 3y ago
  I'll check it out, thanks.
mrweasel 3y ago
The dh tools have a lot of magic to them. Arguably it works rather well, but figuring out how exactly to build a package correctly is difficult. The documentation is pretty bad, so if you want to do anything slightly different than the standard, your going spelunking in the debian directory of existing packages. Debian could fix a lot of the troubles with the existing Debian Helper tools by improving the documentation.
secondcoming 3y ago
Preach! Creating custom debian packages is a path I hate to tread.
otherjason 3y ago
I have had good luck with fpm, which makes it easy to make packages of all different kinds, including deb and rpm: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm
cosmical65 3y ago
For me rpm was relatively easy to grasp, it's basically a shell script and each section has a specific job (building, preparing, copying files etc.) No matter how much I tried I could never grasp deb packaging. The documentation is very sparse and the debhelper commands seem like magic. I couldn't find out what all the different files like .dirs or .install did, so I just gave up.
- soraminazuki 3y ago
  I find RPM specs to be pretty frustrating. Easy cases like packaging GNU Hello is fine, but things get out of control really fast once you fall off the happy path. RPM specs are based simple text substitution. It lacks the flexibility to make adjustments to the build, the power to build good abstractions, and comes with all the same drawbacks of the C preprocessor. On top of that, documentation is lacking for basic macros, language ecosystem support is spotty and scattered across various obscure projects, and SCL packaging is a complete nightmare. The whole design seems dated compared to other solutions.
  - oneshtein 3y ago
    Write a build script in your language of choice and then call it from RPM spec.
    - soraminazuki 3y ago
      At that point, why even use package managers? That approach won't benefit from existing packaging infrastructure at all. Might as well distribute binaries in tarballs instead for simplicity.
      - oneshtein 3y ago
        Slackware uses tarballs, so use Slackware instead. :-/
Aerbil313 3y ago
> No wonder people are attracted to flatpak and snap. And nix. > Creating a installer for mac, windows and linux is a hell of a work Nix gets you mac, linux and WSL support.
- 01HNNWZ0MV43FF 3y ago
  Will look into it. https://nixos.org/download#download-nix https://nixos.org/download#download-nix <--- I'm bookmarking this cause I keep forgetting that Nix can run atop other systems. I have no excuse to not give it a try
  - Aerbil313 3y ago
    This is a way improved[1] version of the official installer, capable of uninstallation among other things, there is no need to use the official one: https://determinate.systems/posts/determinate-nix-installer https://determinate.systems/posts/determinate-nix-installer 1: https://github.com/DeterminateSystems/nix-installer?tab=readme-ov-file#motivations https://github.com/DeterminateSystems/nix-installer?tab=read...
bobajeff 3y ago
The easiest package format I've ever came across was the tgz format from Slackware. From what I remember, you just build and install your software in a fake root then tar gzip it up.
- steve_rambo 3y ago
  This is because it doesn't do very much. Arch Linux's PKGBUILD and Alpine's APKBUILD are an excellent improvement on that, still very simple to use and learn. In most cases the source package consists of a single shell script (unlike Debian's splintered hell) where you have to define half a dozen fields and a couple of functions (build && install). I basically have to relearn Debian packaging from scratch every time I have to do that, but learn Alpine and/or Arch once and you're all set. https://gitlab.archlinux.org/archlinux/packaging/packages/mutt/-/blob/main/PKGBUILD https://gitlab.archlinux.org/archlinux/packaging/packages/mu... https://git.alpinelinux.org/aports/tree/community/mutt/APKBUILD?h=3.12-stable https://git.alpinelinux.org/aports/tree/community/mutt/APKBU...
- oneshtein 3y ago
  It's the same process for all package builders: install build-time dependencies, unpack source archive with a program, configure it, build it, install it to a fake root, validate it, archive it to the package, sign it, then publish it to a repository, update repository index.
pja 3y ago
Binary deb packages are extremely simple. It's just a cpio archive with a couple of tarballs & almost every system integration is implicit. Very easy to build by hand. Last time I shipped a debian package to clients we just had the build system spit out a ready made binary .deb. Much, much easier than faffing about with dhbuild etc.
- linsomniac 3y ago
  My work workflow use `dpkg-deb`: I just create a "build/DEBIAN" directory, populate it with the control file and any post/pre scripts I need, put everything else in the "build" directory where it goes on the end filesystem and then do "dpkg-deb build ." I put all this into a script and do "fakeroot <SCRIPTNAME>".
- rubicks 3y ago
  I usually start with the `dh_make` generated skeleton and incrementally add overrides as I iterate with `gbp buildpackage`. It's not pretty, but it's what I know.
bayindirh 3y ago
> I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are. After doing the first one, I was able to build binary, Debian packages in 5 minutes tops, while chatting with a friend during the process, too. flatpak and snap are designed to solve different problems than OS native packaging paradigms. Also, .deb and .rpm are much more capable and sophisticated than they look on the surface. Lastly, extracting a source and binary Debian package provides great documentation in itself. Lastly, use lintian. That thing is a godsend (and does binary static analysis, too!).

GuB-42 3y ago

Maybe you want a non deb specific packager. cpack (cmake packager) can generate Windows, OSX, DEB, RPM and simple archives. There is also fpm that doesn't support Windows, but supports plenty of packet managers. And possibly many others. AppImage, FlatPak and Snap may actually be worse in that regard, because they are like other distros you have to take into account. So now, you may have to do all of them: deb, rpm, flatpak, snap, appimage, tgz, whatever that's on Windows and OSX, maybe a Docker container too, app stores and mobile stuff, and upload to some npm, maven, crate.io,... It makes generic package manager even more important.

BiteCode_dev 3y ago
I'll check it out, thanks.

mrweasel 3y ago

The dh tools have a lot of magic to them. Arguably it works rather well, but figuring out how exactly to build a package correctly is difficult. The documentation is pretty bad, so if you want to do anything slightly different than the standard, your going spelunking in the debian directory of existing packages. Debian could fix a lot of the troubles with the existing Debian Helper tools by improving the documentation.

secondcoming 3y ago

Preach! Creating custom debian packages is a path I hate to tread.

otherjason 3y ago

I have had good luck with fpm, which makes it easy to make packages of all different kinds, including deb and rpm: https://github.com/jordansissel/fpm https://github.com/jordansissel/fpm

cosmical65 3y ago

For me rpm was relatively easy to grasp, it's basically a shell script and each section has a specific job (building, preparing, copying files etc.) No matter how much I tried I could never grasp deb packaging. The documentation is very sparse and the debhelper commands seem like magic. I couldn't find out what all the different files like .dirs or .install did, so I just gave up.

soraminazuki 3y ago
I find RPM specs to be pretty frustrating. Easy cases like packaging GNU Hello is fine, but things get out of control really fast once you fall off the happy path. RPM specs are based simple text substitution. It lacks the flexibility to make adjustments to the build, the power to build good abstractions, and comes with all the same drawbacks of the C preprocessor. On top of that, documentation is lacking for basic macros, language ecosystem support is spotty and scattered across various obscure projects, and SCL packaging is a complete nightmare. The whole design seems dated compared to other solutions.
- oneshtein 3y ago
  Write a build script in your language of choice and then call it from RPM spec.
  - soraminazuki 3y ago
    At that point, why even use package managers? That approach won't benefit from existing packaging infrastructure at all. Might as well distribute binaries in tarballs instead for simplicity.
    - oneshtein 3y ago
      Slackware uses tarballs, so use Slackware instead. :-/

Aerbil313 3y ago

> No wonder people are attracted to flatpak and snap. And nix. > Creating a installer for mac, windows and linux is a hell of a work Nix gets you mac, linux and WSL support.

01HNNWZ0MV43FF 3y ago
Will look into it. https://nixos.org/download#download-nix https://nixos.org/download#download-nix <--- I'm bookmarking this cause I keep forgetting that Nix can run atop other systems. I have no excuse to not give it a try
- Aerbil313 3y ago
  This is a way improved[1] version of the official installer, capable of uninstallation among other things, there is no need to use the official one: https://determinate.systems/posts/determinate-nix-installer https://determinate.systems/posts/determinate-nix-installer 1: https://github.com/DeterminateSystems/nix-installer?tab=readme-ov-file#motivations https://github.com/DeterminateSystems/nix-installer?tab=read...

bobajeff 3y ago

The easiest package format I've ever came across was the tgz format from Slackware. From what I remember, you just build and install your software in a fake root then tar gzip it up.

steve_rambo 3y ago
This is because it doesn't do very much. Arch Linux's PKGBUILD and Alpine's APKBUILD are an excellent improvement on that, still very simple to use and learn. In most cases the source package consists of a single shell script (unlike Debian's splintered hell) where you have to define half a dozen fields and a couple of functions (build && install). I basically have to relearn Debian packaging from scratch every time I have to do that, but learn Alpine and/or Arch once and you're all set. https://gitlab.archlinux.org/archlinux/packaging/packages/mutt/-/blob/main/PKGBUILD https://gitlab.archlinux.org/archlinux/packaging/packages/mu... https://git.alpinelinux.org/aports/tree/community/mutt/APKBUILD?h=3.12-stable https://git.alpinelinux.org/aports/tree/community/mutt/APKBU...
oneshtein 3y ago
It's the same process for all package builders: install build-time dependencies, unpack source archive with a program, configure it, build it, install it to a fake root, validate it, archive it to the package, sign it, then publish it to a repository, update repository index.

pja 3y ago

Binary deb packages are extremely simple. It's just a cpio archive with a couple of tarballs & almost every system integration is implicit. Very easy to build by hand. Last time I shipped a debian package to clients we just had the build system spit out a ready made binary .deb. Much, much easier than faffing about with dhbuild etc.

linsomniac 3y ago
My work workflow use `dpkg-deb`: I just create a "build/DEBIAN" directory, populate it with the control file and any post/pre scripts I need, put everything else in the "build" directory where it goes on the end filesystem and then do "dpkg-deb build ." I put all this into a script and do "fakeroot <SCRIPTNAME>".
rubicks 3y ago
I usually start with the `dh_make` generated skeleton and incrementally add overrides as I iterate with `gbp buildpackage`. It's not pretty, but it's what I know.

bayindirh 3y ago

> I've had to build a deb package once. It's crazy how few docs and resources there are to do so, and how of poor quality they are. After doing the first one, I was able to build binary, Debian packages in 5 minutes tops, while chatting with a friend during the process, too. flatpak and snap are designed to solve different problems than OS native packaging paradigms. Also, .deb and .rpm are much more capable and sophisticated than they look on the surface. Lastly, extracting a source and binary Debian package provides great documentation in itself. Lastly, use lintian. That thing is a godsend (and does binary static analysis, too!).