this post was submitted on 09 Aug 2023
29 points (100.0% liked)
Linux
48149 readers
973 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
The problem there isn't that
env
isn't available (it is, we have coreutils in stdenv) but rather that/usr/bin/env
(that specific path) does not exist in the sandbox.Yikes, you don't want that.
I didn't read the issue in full but, since everything is pre-downloaded, you can always fix these scripts.
For the auto-generated configure script for example, you'd have to patch the build step which generates the configure script to put in
${coreutils}/bin/env
rather than/usr/bin/env
. Simple as that.3rd party repositories can be patched during their respective fetches. You have to inject them anyways since there's no way to download 3rd party repos during a build.
You have to differentiate between the Nix expression language and using Nixpkgs' frameworks to define packages here. These are two entirely different skillsets with only a slight dependence on the former by the latter.
If you take a look at your expression, it only required fairly basic Nix syntax: Simple function calls, declaring recursive attrsets, string interpolation and attribute access. Most packages are like this.
Figuring out which attributes need to be set how and what that means is an entirely different skillset. Defining
patchPhase
in that attrset is trivial syntax-wise but figuring out what needs to be substituted using which stdenv "library" function is something else entirely.Looks pretty good btw. I'd look into whether the build could be coerced to link against Nixpkgs' versions of those libraries though instead of vendoring dependencies. Especially security-critical stuff like openssl. That'd probably also save you the trouble with the interpreter.
If you take a look at the build definition, there's this handy dandy
USE_3RDPARTYBUILD
option.I'd wager if you did
cmakeFlags = [ ... "-DUSE_3RDPARTYBUILD=OFF" ];
andbuildInputs = [ asio zlib openssl ... ];
(frompkgs
, not your fetched sources) it'd just work. (Might needpkg-config
innativeBuildInputs
but I don't think it uses that and will instead discover those deps via cmake.)If you can get rid of the vendoring, feel free to submit that to Nixpkgs ;)