I’m building my own distribution, and as a part of that a package manager. I’d like to do something unique, where inside the package manager’s “store”, you can have multiple package versions; like Nix or Guix. You should be able to flip between them at a fly with something like Debian/Suse/Fedora/etc’s update-alternative's tool, and call ones besides the primary ones.
My question is; how do these systems work? Specifically how do they handle dependencies?
For example…
say that
foo@1.0 depends on bar@1.0
foo@2.0 depends on bar@2.0
baz@1.0 depends on bar@2.0
so foo@2.0 is the default version. no issue, it depends on bar@2.0 like baz@2.0 however, now the user wants to do update-alternatives foo@1.0. so we have to roll back bar to 1.0, but this breaks baz@1.0. Or. the user wants to run foo@1.0 while keeping 2.0 as the default. I guess you could do tomfoolery with PATH and LD_LIBRARY_PATH, but I’m guessing that’s not what those distributions do. Also guessing they don’t use a chroot. I’d love some insight into this
Last I checked, update-alternatives doesn’t do that. It requires all the packages you choose between to be installed concurrently. What it does is choose which one you are running when you type a command.
If you want to build a package manager which allows conflicting versions of software to be installed, you need to structure your distro around that.
Nixos does this by not having system versions of applications and libraries but specific versions. This has huge advantages when it comes to dependency management but comes with a bunch of disadvantages because applications are often built with a traditional linux filesystem hierarchy which nixos doesn’t have.
Fedora silverblue, takes a different approach. It has a small immutable ostree-based filesystem and then uses containerized applications. The design is totally different but the effect is similar. The applications are not directly connected to the underlying system libraries and not stored in a traditional linux filesystem hierarchy.
I haven’t looked at guix in a while but, if memory serves, I believe it is doing something conceptually similar to what nix is doing.
Either way, if you want to build a distro that is fundamentally different like one of those. You either will need a sizable team of contributors or to base your distro off some other project. There is just too much too implement by yourself if you want to redesign the way a Linux system works.
Ah, so it’s for switching between different packages that can provide one file; got it.
Yeah, if I remember correctly, they’re stored in the Nix store (/nix?). But then, how does one point some executable to run with some library, or some version of an executable? I’ve always found Nix and Guix confusing.
Fedora silverblue indeed uses containers for software; so essentially simple chroots (or perhaps user namespaces). That’s viable, and I’m considering that solution as well.
I don’t aim for it to be anything that anyone uses; just a project that I can use to play around with different concepts. Perhaps, though, it’ll gather interest and end up being something that people will contribute to… I’m starting off with building simple components and using them independently, and I should be able to hack a LFS install together (but using my own tools). But yeah, not gonna make anything usable on my own (almost) everything starts off as a one-man effort though!
Thanks for writing that detailed reply!
(btw, still open to suggestions on how else I can handle this. Currently, I’m thinking something similar to silverblue. packages can be installed [“overlayed”] into the Rootfs [with their files tracked], or installed in containers; basically contain a tiny little FHS with all the parts they need in the “store”. , and then a chroot can be set up, with all the libraries needed linked. then, someone can do packagemanager run package@version/usr/bin/blah, for example, and it will run it in a chroot that shares [potentially via mounts] all of the root file system, besides for the files in the tiny little fhs, which will overwrite those. no idea how to do that with a chroot!)
Explicitly. Instead of relying on a search path or conventional location like /lib or /lib64 the libraries are installed into the nix store and than the applications are built against those libraries.
That’s interesting; I didn’t know you could hardcode a path to a library. What about if a package wants to call an executable file, though? How would that pin a version?
Seems great, I’ll see if I can use that without systemd. If not, I’ll just use systemd for now Thank you!
God even the question hurt my head! We have some very clever people on this forum (@jonathon@dalto ) and I for one am extremely grateful they are willing to share this knowledge with us.
Edit : Sorry i thought the topic was finished! Forgive me for interuppting!
In nix it is done by simply calling the full path to the file. So instead of calling grep, it calls something like /nix/store/0kcx6s8gxysnygd8kxa502xfdfm1n28y-gnugrep-3.4/bin/grep. Of course, Nix has cool ways to make this easy but explaining the mechanics on all that is a bit beyond a friendly forum post. Better to read the nix docs.
(almost) everything starts off as a one-man effort though!
and I for one am extremely grateful they are willing to share this knowledge with us. 