Synaptic is exactly the right level of UI for me, and I do use it especially for searching and simple installation, but it has at least three major issues that years later are still WONTFIX'd:

1. Locking a package version in Synaptic won't lock it for CLI apt, and vice-versa. Boggles the mind; it should be using the same mechanism, but it's not. No idea why they invented that fifth wheel.
2. It doesn't display 32bit and 64bit packages together. 64bit packages shadow the 32bit ones. You have ot go to the architecture tab to see the 32bit ones.
3. It always does something every time on startup and after packages are installed that is just sloooow and the GUI is unusable during this time. Some refresh or rescan, I don't know. It's a few seconds, but it's always a frustrating few seconds that screw up the flow. Borderline intolerable on weaker systems. No progress bar, no indication of what it's doing.

I wrote up a guide based on what I learned so far: /viewtopic.php?pid=62061

I gave up on the wiki idea after waiting hours in chat like I was in the damn backrooms.

Negative. I installed 6.0 and 6.1 several times. The "installer components" screen was always part of the process, but selecting no components gave only the limited filesystem options that the OP mentions. I was confused, because I have been using ext4 as my choice for many years. Experimentation showed that one of the options (I don't recall the name exactly - Volume Manager or something like it) was necessary to enable the full selection of filesystems.

He didn't "skip" it. He just followed the default route. That step is optional and if I recall it even stated in the instructions that this is probably not necessary to do. It took me a while to figure it out myself, much to my frustration.

Installing modern Linux on ext4 is not some "extra" step, it's bog-standard.

So surely it's been documented with an erratum note on the download page? On the installation instructions page? No? Why the bleep not?

I just did another mini-investigation. The link is regenerated by /usr/lib/bin/trigger_sv setup which is also called straight from /etc/runit/2 The comment says "sync available services". The function seems to be something to run once at install time or upgrade to discover services and enable them by default, not every boot after a user has disabled the service. In any case, totally undocumented. In fact, misdocumented, as I explained.

By my count we're up to at least four critical ways that runit does things contrary to its own specification.

This is not a new or experimental package. runit is over 20 years old. There is no excuse good enough.

This is a long-running issue with DNS, and has been happening for at least a year. It happened to me several times. I don't know the exact cause or if the admins have tried anything serious to fix it. You can fix it by switching your DNS server to one of google's -- 8.8.8.8 or 8.8.4.4 -- those seem to always resolve the address correctly. Alternatively, you can change your sources.list file to point to a local mirror, such as ca.deb.devuan.org.

Previous posts about it:
/viewtopic.php?id=7416
/viewtopic.php?id=7066

Okay, I finally understand what's happening.

Firstly, yes, runit starts sysvinit scripts, despite docs to the contrary. This is triggered from /etc/runit/2, which calls /lib/run/run_sv_scripts. (Good name, I guess.) All the online documentation is hopelessly out-of-date/wrong. I'm still angry.

run_sv_scripts tries to be clever by checking if a symlink with the name of the service exists in /etc/service/, precisely to prevent double-starts by ignoring sysvinit scripts for services that runit starts. This check works, and prevents slim from being started at this point. (Notably, this directory is symlinked to /etc/runit/sunsvdir/current/, where individual service dirs are symlinked to /usr/share/runit/sv.current/; foreshadowing.) Then follows another check (not reached in my case), which is in fact broken, which brings me to...

There is a runit service called dbus.dep-fixer which tries to ensure certain services that depend on dbus are really started, because the earlier start (by run_sv_scripts) might have failed due to timing issues. This script also tries to prevent double-starts by runit and sysvinit by looking for services that runit "knows about" in /etc/sv/. This check also appears in run_sv_scripts. This check is broken.

While online documentation (again, wrongly) says that runit service definitions (active or not) should be in /etc/sv, they are in fact in /usr/share/runit/sv/. There is no symlink from one to the other. /etc/sv contains some getty-tty stuff I don't understand, but it doesn't have the regular services (inlcluding slim) that runit manages. Hence, this check fails to find that slim is already a runit service, so the sysvinit script is run at this point.

And of course, runit tries to run slim as its ordinary service. The race happens between the regular slim service and dbus.dep-fixer.

Diagnosis: Someone moved around the runit directories and tried to duct tape it over with symlinks, but failed.

Fix: Add the line [ -d "/usr/share/runit/sv/$name" ] && continue to the loop in /usr/share/runit/sv/dbus.dep-fixer/run This allows runit to start slim as intended and prevents the double-start through the sysvinit script.

Consider this a bug report.

I'm out, and still angry.