this post was submitted on 18 Feb 2024
128 points (93.8% liked)

Linux

48682 readers
387 users here now

From Wikipedia, the free encyclopedia

Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).

Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.

Rules

Related Communities

Community icon by Alpár-Etele Méder, licensed under CC BY 3.0

founded 5 years ago
MODERATORS
 

Distro agnostic packages like flatpaks and appimages have become extremely popular over the past few years, yet they seem to get a lot of dirt thrown on them because they are super bloated (since they bring all their dependencies with them).

NixPkgs are also distro agnostic, but they are about as light as regular system packages (.deb/.rpm/.PKG) all the while having an impressive 80 000 packages in their repos.

I don't get why more people aren't using them, sure they do need some tweaking but so do flatpaks, my main theory is that there are no graphical installer for them and the CLI installer is lacking (no progress bar, no ETA, strange syntax) I'm also scared that there is a downside to them I dont know about.

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 10 months ago (1 children)

If you maintain upstream software and do not have an interest in learning and using Nix, please don't put the burden of packaging software in Nix onto yourself. Nobody in their right mind would expect you to package anything for a dozen distros; that's not how distros are supposed to work.

Leave it to someone who is interested to package your software in Nixpkgs. Your "job" is to make your software better and provide a sane way to build your software that packagers can rely on (i.e. no assumptions where things are or are supposed to go, document your dependencies and build processes).

If you do want to go the extra mile, offer your help in assisting packaging in the appropriate channels. You know the technical details of your software and Nix users how Nix packaging works but the reverse mostly isn't true, so cross-pollination can be super helpful here.
Even just things like testing that your software works as you expect when the packaging is touched in some way (i.e. an update) is incredibly helpful. (If saw a package update PR with the upstream maintainer's approval stating that it works as they expect, I'd merge immediately.)

If packaging for Nix is a burden for you, please just open an issue on Nixpkgs with links to your packaging/build documentation and let someone else do it for you.
As a Nixpkgs committer, I'd much rather have someone invested in Nix build and maintain a package than an upstream maintainer who somehow feels obligated to do so but has no experience or actual interest as the former is more likely to produce good code and keep maintaining the package.

[–] [email protected] 1 points 10 months ago (1 children)

Sure. My point is that it's trivial to make and test packages for many distributions; it is harder to do so for Nix. It tends to get your software out there and used faster if you bootstrap the packaging - immediately, if you have an AUR account.

IMHO, Nix is unreasonably harder. There are frequently small projects that don't get packaged for most distros. When I encounter these, I have a couple of options:

  • Submit a packaging request. Hope someone is willing to accept it. Wait until it is packaged.
  • Install it from source and let it pollute the core system. Hope this causes no issues. Manually track and maintain the installation. If lucky, the software lets itself be installed somewhere non-standard, in which case I can use stow and keep things a bit cleaner.
  • Throw together a package for it and let my distro manage the installation.

The third option is preferrable to the others, for a variety of reasons, and it's easy on most distros. On Arch, I might submit the package to AUR, but I'll often just make a -git package and install it locally.

[–] [email protected] 1 points 10 months ago

It tends to get your software out there and used faster if you bootstrap the packaging

It's fine to provide some sort of "official" binary package in some common format such as a Flatpak, Appimage or even just a plain old tarball but trying to package something for many different distros is insanity IMHO.

My point is that it’s trivial to make and test packages for many distributions; it is harder to do so for Nix.

it’s easy on most distros

It all depends on what you're used to and how cursed the project's build process is.
For sane build systems, I find it much easier to package for Nix now that I know its intricacies. I wouldn't want to go back to weirdly sourced bash scripts without proper structured data types or any sort of abstractions or mechanism for extremely common patterns.

On Arch, I might submit the package to AUR, but I’ll often just make a -git package and install it locally.

It's the same for NixOS. When I encounter something that somehow isn't packaged in Nixpkgs yet, I usually start out by simply packaging it in my local nixpkgs checkout.
There are handy tools to generate the little boilerplate there is and, if the package uses a reasonably standard build system, it usually only takes adding the dependencies and one or two tweaks to have a working package that is then also ready for submission to upstream Nixpkgs.