Request for feedback for packeging software for a newbie (s6-overlay package)

Development
1

Hi, I am a new user and this is my first ever attempt to package someone else’s existing software with nix. I chose to make a package for s6-overlay which is a service supervisor for docker, because I am currently interested in building docker images using nix (I was a bit inspired by this set of papers: 1, 2 ), and there wasn’t a package for this on nixpgks. Unfortunately I don’t really know this software well enough to test it thoroughly, but it seems to be working.

Am I doing this correctly mostly? Any feedback is welcome :). What more is to be done if I were to attempt to contribute this to nixpkgs(besides more testing)?

Here is my code: GitHub - Dr-McFish/s6-overlay-nix: Nix packages for the s6-overlay software for docker containers · GitHub

Disclosure: I have had some help form LLMs but I tried to be intelligent about it; trying understand what I am doing instead of blindly copy pasting.

3 Likes
2

Hey. Thank you for your willingness to contribute. Nixers typically avoid Docker if they can help it, I suppose. But if you think s6-overlay is of use, I think the next step is to convert that package you have into a draft Nixpkgs pull request. Good luck.

1 Like
3

Your project is really great. I’m currently running containers on nixos. I have many containers. Previously, I always wanted to switch to a way that can be configured as conveniently as nix and also run multiple services in one container, such as php programs. The only solution for containerization like this is to use a management tool like s6 to run php php-fpm. But I always feel that s6 doesn’t seem to be very suitable for nix. nixos should have a native implementation method similar to systemd.

1 Like
4

Right, I use Podman and CRI-O instead. :wink:

I used Finit once for a container, although not sure how amenable to normal containers it is (I ran a k3s node in it, so --privileged and other permissions were involved, since moved it into a MicroVM to use eBPF-based things).

I’m actually quite a big fan of containers and Kubernetes, although I do find the store duplication in dockerTools to be a waste, especially if the host runs Nix.

I’m still not sure exactly what modular services are, but AFAIK I’ve seen people talking about using them in similar contexts. Also, depending on where you want to run the containers (if you can just run them on 1 NixOS host) you can use systemd-nspawn-based NixOS containers.

Also, this reminds me, sometime I should build a module system layer for dockerTools/nix-snapshotter that you could make something similar on.

5

Looking closer at this code:

  • You should set formatter.${system} = pkgs.nixfmt-tree in flake.nix so you can run nix fmt to format Nix files automatically.
  • You probably want cp -r output/rootfs-overlay-noarch/. $out instead of cp output/s6-overlay-noarch.tar.xz $out/ in s6-overlay-noarch.nix, which just puts the tarball in $out.
  • You can remove pkg-config = null; and references to it from s6-overlay-helpers.nix, also link to the correct URL at GitHub - just-containers/s6-overlay-helpers: Small binary utilities, specific to s6-overlay · GitHub rather than skarnet.org. also, it’s probably only for Linux platforms, so set that instead of platforms = platforms.all.
  • AFAIK with lib; is also bad pratice.
  • I don’t think this is quite right for cross-compilation either, not sure:
      nativeBuildInputs = [
    execline.dev
  ];
  • Also you can remove the ? nulls AFAIK

If you address these issues and make a nixpkgs PR for s6-overlay-noarch and s6-overlay-helpers I’ll be happy to review further there.

1 Like
6

Thank you very much for taking your time to provide this feedback! (the tarball thing is a bit embarasing haha). I have implemented most of it but I have 3 little questions:

  1. Do you agree that pkg-config is in fact useless here, and therefore not worth including?
  2. nsss is listed as an optional dependency, which is why I put ? null. It probably should be off by default. What is a good way to do that.
  3. My reasoning for nativeBuildInputs = [ execline.dev ] is because that is where the header files were. If you can explain why “his is quite right for cross-compilation” I would appreciate it :slight_smile:

I want to do more testing before submitting to nixpkgs

1 Like
7

Yep. pkg-config is mostly useful when compiling software to find out where the libs are, and if you don’t need it to find libraries to compile s6-overlay-helpers (evidence shows you don’t as you already have it as null) with it’s good to remove.

The regular nixpkgs way to do this would normally be to add withNsss ? false, the the package arguments so you could use .override { withNsss = true; } to enable it, and always have nsss passed into the package.

I’m honestly not sure, I don’t do any pkgsCross-style cross-compiling but since it is just headers it’s probably fine. I’ll do some more poking around at this to test and make a PR to your repo to do the right thing. Actually, with --with-include=${execline.dev}/include I just confirmed we can get rid of nativeBuildInputs entirely.

Also, instead of configurePhase in s6-overlay-helpers you can just set configureFlags to an array of all flags to be passed to ./configure.

1 Like
9

We should actually be using pkg-config in general instead of manually declaring paths, but skaware-packages does not even copy out .pc files into the outputs:

10

What is problem with manually declaring paths?

11

Because it’s error prone and we have a well-established solution to avoid all of that boilerplate.

Also I’d drop this installPhase, it basically does nothing new.

See https://nixos.org/manual/nixpkgs/unstable/#ssec-install-phase.

2 Likes