Linux

48033 readers

943 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

Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
No misinformation
No NSFW content
No hate speech, bigotry, etc

Related Communities

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

founded 5 years ago

MODERATORS

[email protected]

Does Nix's break from FHS cause problems? (lemy.lol)

submitted 9 months ago by [email protected] to c/[email protected]

31 comments fedilink hide all child comments

I know that a lot of what Nix does is working around its break from FHS, but I can imagine there are still things that seep through. Are there any unsolvable problems due to this?

I saw on this post that it is possible to use FHS on Nix. Does this solve all potential issues then?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 15 points 9 months ago (7 children)

You may be interested in reading this post about the process of packaging Steam.

tl;dr: It's mostly an annoyance reserved for packagers to deal with. Dynamically linked executables can be patched in a fairly universal fashion to work without FHS, so that's the go-to approach. If the executable is statically linked, the package may have to ship a source patch instead. If the executable is statically linked & close-source, the packagers are forced to resort to simulating an FHS environment via chroot.

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

So that means packaging software for nix is a pain, compared to, say, gentoo or arch's AUR, but only for a small subset of packages.

I'll keep this in mind as I'm exploring if I should switch from Gentoo.

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

I would say it’s actually easier in many cases. Nix has really fantastic packaging tooling. You do have to learn a bit of the nix language, however (not become an expert).

The issue comes when trying to build from source. In most other distros, ou just follow the readme. In nix, you have to package it.

[–] [email protected] 2 points 9 months ago (2 children)

If I am packaging software for gentoo, all I have to do is translate the build instructions from the project's documentation to gentoo's package recipe. In nix, it seems that it is not that simple and you'll have to do some exploration. Am I wrong?

[–] [email protected] 3 points 9 months ago

It's just that most (if not all) build system in the source code package would assume some level of FHS compliance.

For example, they would install:

executables under /bin /usr/bin
libraries under /lib or /usr/lib
sysconfigs under /etc
manpages under /usr/share/man
and so on...

These build systems would include options to change these, but you'd then have to change all these values to adapt to nix structure. While it's all been done by the nix package maintainers, you'd have to do all that if you're to come up with a new package.

In the FHS compliant distros, the maintainers wouldn't need to change anything since these values are already set to the values they want (there are actually minor details they'd change, but that's another topic).

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

If I am packaging software for gentoo, all I have to do is translate the build instructions from the project’s documentation to gentoo’s package recipe.

It's the same for Nixpkgs.

In nix, it seems that it is not that simple and you’ll have to do some exploration. Am I wrong?

In well behaved build systems, it's likely easier to package than most other distros. If it's not as well behaved you will have to do some "exploration" and the complexity can get quite out of control if the build system is exceptionally terrible.

Here is the package for the GNU hello program which uses a well-behaved build system:

https://github.com/NixOS/nixpkgs/blob/94b11073db6a7ca5733bc2d45378d800d9542975/pkgs/by-name/he/hello/package.nix

If you ignore the optional passthru.tests, this is very simple. You provide metadata, sources etc. to the generic mkDerivation function and that's it. The most complex non-standard thing this derivation does is enable the build system's tests.

You don't even need to run the provided build instructions because Nixpkgs' stdenv abstracts those away. If it finds a makefile, it'll automatically run make and make install with the correct flags for instance. Same for other standard build systems; if you pass cmake into nativeBuildInputs, it'll attempt to build, install, check etc. using cmake's standardised interfaces.

If the build system is poorly behaved however (like for instance Anki's), you will have to get into the weeds and do some rather advanced things:

https://github.com/NixOS/nixpkgs/blob/94b11073db6a7ca5733bc2d45378d800d9542975/pkgs/games/anki/default.nix

Luckily though, most packages aren't like this.

[–] [email protected] 2 points 9 months ago

Thank you for the thorough comment!

load more comments (4 replies)