Do you have a reason not to use systemd? Yes, it might be slower to boot than other inits, but the units are so nice. (Not trying to convert you, just curious about why you seem to avoid it)

Installing Gentoo is fun! It can be done without install media. Just extract the stage3 archive to a partition, mount system directories correctly & just chroot in! Now you can have the handbook open in a browser next to the chroot. Though, I haven’t finished the install yet. I’ve had it in a half-done state for a while.

I can program in C++ & don’t have much against it, I just love Rust. Also, for security, Rust is just better. Everyone makes misrakes, so why not make the compiler check your work? Especially when it comes to concurrency. With Rust, never I have to about worry race conditions & data races again. (Kind-of trying to convert you, but Rust isn’t perfect, or ready for everything yet, sadly)

With the compilation, I was wondering how good the support for partially compiling dependencies was. For example:
packages: foo, bar, baz
bar depends on foo
baz depends on bar

What happens if I compile bar myself?
If foo updates, I may need to rebuild bar, I need to do that manually on Arch.
What about baz? It depends. It might work with my locally compiled bar, or it might not. Either way, pacman doesn’t care.

I’ve been toying around with a new Rust-written™®© package manager that would support that. It’s still very early in development & I have a few other personal projects in the way, too.
A few thoughts I have about it:

• The “database” format used by pacman is simply insufficient. (I mean the local db, the sync db is fine, IIRC)
• It should be possible to cascade testing repo installs. (mark the extra repo compatible with extra-testing and the same with core & core-testing, with the non-testing repos having higher priority. Install extra-testing/bar, the dependencies, like foo are pulled from the testing repos, if available. This should cascade. Now, you can selectively use packages from testing without breaking anything.)
• Add new repo formats, like repo-src (official PKGBUILDs) & AUR (stored in a different way from official build scripts & different trust levels, require reviewing build script) that build when installing & cascade similiarly to the previous point.
• Allow using the legacy (current) DB format, but without support for the fancy new features
• Allow tagging paclages with extra metadata, for example to prevent packages from being rebuild (or built at all) unnecessarily.
• It should be compatible with pacman’s options & behaviour. Some tools also need to be redone, but I have already started on this.
• The Arch formats (.pkg.tar*, PKGBUILD, db) are not designed for this, at all. I think that packages can be optionally manually tagged, but this should err on the side of rebuilds, and I’d also like to redesignd both the package format & build scripts/tooling. Like I said, the db is just insufficient & needs to go.

This is still very early in development, but I’d like to get it done at sone point.

It would combine the worst parts of both Arch & Gentoo (compilation, no use flags, complex dependency solving) in a gradual way (build the fish shell [yes, I use fish. I used to use zsh with plugins, but fish just did everything, but better & faster] today, next week build ffmpeg & dependents, next month, build libc & watch most of the system get built).
It would be nice to support parallel building of unrelated packages, as not everything scales well.

Dependency cycles/conflicts/versions are going to be nightmarish to solve for repo packages, then it also needs to work for AUR.

I’m not sure if I’ll ever get the package manager to a usable state, though.