You might be interested in git-annex (see the Bob use case).

It has file tracking so you can - for example - "ask" a repository at drive A where some file is, and git-annex can tell you it's on drives C and D.

git-annex can also enforce rules like: "always have at least 3 copies of file X, and any drive will do"; "have one copy of every file at the drives in my house, and have another at the drives in my parents' house"; or "if a file is really big, don't store it on certain drives".

A neat trick I use to figure out what apps belong to what packages is to run realpath $(which $app_name) - this outputs the full, canonicalized path to the store item, which should include the package name.

I would do a search (e.g. using grep) through a local copy of the Guix repository to figure out what services are providing the packages, then modify the service configurations (or use modified versions of services, if needed) to remove them. This might be a tedious solution, though.

I haven't found a need to do it, but a (modify-services ... (delete pulseaudio-service-type)) in your operating-system declaration might do what you're asking? I don't think this is necessary though. As far as I'm aware, applications that attempt to use Pulseaudio will be transparently rerouted through pipewire-pulse, which is already configured by home-pipewire-service-type. I am also on GNOME, and I haven't noticed any breakage in this aspect using it.

If you're unsure that it works the way you want, you can always try the configuration out and see how it goes (note that I had to re-log in for the wireplumber service to start properly).

I've never tried putting it in the system configuration, but I imagine it wouldn't work as it depends on Guix Home services.

If you haven't used Guix Home before, the home-environment record doesn't have required fields like operating-system does so it's fairly easy to get started with.

(use-modules (gnu)
             (gnu home services desktop)
             (gnu home services sound))
(home-environment
 (services
  (list (service home-dbus-service-type) ;home-pipewire-service-type needs this
        (service home-pipewire-service-type))))

There is, actually! It's available as a Guix Home service: home-pipewire-service-type was introduced around the end of December, and you can see documentation for setting it up in the manual.

When using this service, pipewire-pulse is used by default without any extra configuration.

Was not aware of this, thanks! Looks like it does, with a notable difference being that Cryptomator has better cross-platform support in exchange for not having file size obfuscation.

The CryFS developers have a comparison page here that might help you decide what to use. There's a summary table at the bottom that gives a comparison of features between encryption filesystems if you don't feel like reading through it all.

I personally use and would recommend CryFS because it's the only one (that I'm aware of) that plays nice with data synchronization software (i.e. doesn't store the container as a single file) while keeping the directory structure encrypted.

Does Guix fit your criteria, perhaps? If you haven't heard of it, you can think of it as Nix with a Lisp frontend.

I unfortunately am not very experienced with containerizing packages so I can't say much, but I know you can do it; the Nonguix channel employs containers for some proprietary software.

Like Nix, Guix has all that building-from-source stuff you'd want from Gentoo. There's recently been work on making parameterized packages (the Guix equivalent of USE flags) a thing, but it's still work-in-progress.

Ignoring the steep upfront cost of learning it, I'd say Guix makes it incredibly easy to add your own packages. Here's the custom packages I currently have in my dotfiles repository. I can import one to my main config file, add the package, and it gets included in my environment the next time I reconfigure it.

As for patches, I can't make any comparisons since I'm not familiar with Gentoo, so I think a code snippet is probably better for you to judge if you'd like it.

(define-public custom-pkg
  (package
    (inherit pkg)
    (name "custom-pkg")
    (version (package-version pkg))
    (source (origin
              (inherit (package-source pkg))
              (patches
               (list (string-append (dirname (current-filename))
                                    "/fix-some-thing.patch")))))))

(define-public custom-pkg
  (package-with-patches
   pkg
   (list (string-append (dirname (current-filename))
                        "/fix-some-thing.patch"))))

Not sure if this addresses your concern about multi-architecture support, but the Foreign Architectures section of the manual discusses what you can build to.

EDIT: So I was curious after posting this because usually the CLI often has much less verbose options (like --with-input for replacing inputs), and I started wondering if there was any procedure that would make this simpler. Turns out there is :) I've included it under the example. Although, I suppose I should have mentioned you could write your own if you really wanted to.

Could you elaborate on why you think Guix will attempt to pull systemd? As far as I'm aware, Guix doesn't impose any hard requirement on systemd when installing it on a foreign system; the manual (particularly 2.1 Binary Installation) simply provides instructions for setting it up on systemd and Upstart.

I just found this blog post about setting up Guix on Void Linux if it helps at all.

I remember having this issue, albeit not as workflow-disrupting as you've had it so I never bothered actively searching for a solution. I can confirm however that there is definitely a solution; at some point in my migrations to different distros, the problem stopped showing up, and right now I actually can't reproduce the problem - labels are displayed correctly for me, both on my existing drives and new partitions that I create.

After some digging (and a sleep-deprived me smiting my boot partition during my investigation and having to fix that, LMAO - I never thought it'd happen, but Guix saved me from a reinstall), I found that LUKS1 has some kind of limitation that makes Dolphin not display the label as expected according to this and my own testing, which may be your problem if your drives are still using LUKS1. The Arch Wiki has a section on how to convert to LUKS2 here.

At the very least, if this is not the solution for you, I can say with certainty that it is fixable!