On plant - update 2

Continued musings about plant on a saturday evening, still not 100% verified and opinionated as long as I don’t double check with my existing notes. It’s a bit chaotic, just taking notes.

So, what exactly do I want?

First it’s mostly an experiment at this point.

I’m contributing to Guix, I’m contributing (rarely) to Nix, and I’m a pkgsrc developer. I’ve used and packaged for various other package managers in the past. And I really am unhappy with all of them, all have nice features, and all make compromises at some points, all make me annoyed when working with them for too long.

  • Guix was the best of all of them, but I got annoyed with how testing (or the lack of, sometimes) worked with updates, you could rollback, but you effectively still have rolling release when it would make much more sense to freeze versions and seal packages when you will never touch them again, keep old versions around as code (I got annoyed when for some reason I needed yet another old software again which required steping back 5 years in git. arguably you should not do this, but sometimes you need to build a 20 years old perl version or whatever I wanted to do). Your codebase grows (one approach: decouple as much as possible) and you have to maintain more versions (you could still have virtual versions by basically moving alias pointers around for updates).
  • pkgsrc is really good for portability, where Guix focuses (so far) on one kernel, one libc, and has a different set of goals. pkgsrc makes me miss “inheriting” packages in guix, atomic updates, and other things you start to take for granted when you have worked on guix for 5 years. Some work in pkgsrc can be augmented from what we learned in guix, but it’s not fair to compare both.
  • Nix is where Guix started, but taking different compromises, different directions than Guix, yet exchange of research. I’m no fan of the nixlang, but that’s just preference and doesn’t prevent me from writing in it.

I could happily settle for Guix if it wasn’t for a few nitpicks where the most unchangable ones can be reduced to code structure and certain parts being unchangable.

Before I dropped/indefinitely paused infotropique/OS core, I reworked my fork of Guix in a way that some issues were addressed, but the amount of work and time to rebase on a newer guix version made me reconsider using guix for small gains in it. I effectively had something which wanted to go in a new direction, but running with an engine I had no full control over. Notes prior to joining NetBSD shifted to the point where I often came back to basically wanting NetBSD but structured differently together with a package manager but not as in the old “this BSD can be dissected like Linux Distributions” mistake.

plant is my ideal package manager, and so is infotropique OS/core constructed from it in templates.

It’d base on MesCC, and some core tools.

As roughly listed here already:

  • language energy consumption is a weird requirement for a package manager, but it’s an idealized goal to use a language which is rather efficient than wasteful with resources.
  • must be documented in extensive detail to remove the concept of a one single knowledge keeper
  • must be extensible with custom extension
  • must hold no opinion about content it is used for to distribute, in other words you should be free to use it for whatever purpose fits your usecase
  • should encourage reproducible builds
  • should encourage build recipes which promise to be build reliable regardless of time or system (frozen DAGs)
  • must neither encourage nor default to distribution via longrunning build-machines
  • should encourage sharing receipes and built artifacts with a group of people which might be interested in the same topics;
  • should be built and maintained on an interest-driven sharing community
  • should encourage bootstrappable build practices
  • must not include an entire operating system or tools to build it; if anything the ability to do so should be an extension
  • must include (read: package) tools which enable and help self-governance (for exchange of recipes etc)

Since the idea is to get to an modular extensible approach to package managers, we want the core to be relatively small and where necessary you should be able to replace the code.

It seems to point at some involvement of Lisp again or one of the few other languages which allow this type of code to be written.


In https://issues.guix.gnu.org/41286#1 which started my more public effort of porting Guix to NetBSD, Ludovic Courtès writes:

Hi Nikita,

Nikita Gillmann skribis:

as mentioned in IRC I have begun porting Guix to NetBSD (with the path taken not yet decided upon, just plain building guix itself for now).

Glibc provides argp. Arguably we don’t have to check for argp because Guix targets glibc. But I am quiete certain that there will be people who will attempt to do what I am doing and run into this.

Guix targets glibc-based systems, so as you write, it’s reasonable to assume argp is present.

Also, using AC_CHECK_HEADERS doesn’t achieve anything: it only defines ‘HAVE_ARGP_H’ to zero or one.

Last, I don’t want to discourage anyone from porting, but I also want to be clear about what it entails. I’m strongly in favor of supporting only glibc because: (1) after all, it’s about GNU as a system, and (2) my experience with Nixpkgs is that supporting multiple C libraries is just too much work to maintain good support.

Thus I’m closing for now.

In a chat today with Janneke of GNU Mes I got enough pointers to start with adding support for NetBSD to mes. It’s a start, but it will take a long time with everything else going on in my life.