Why do you want to use the command seatd-launch dwl.
Is seatd running already?
Is there a dwl running already?

Why shouting?

libncurses5 is found in daedalus/main.
Assuming you are now on excalibur, one option is to add the old repository sources to your sources.list, e.g., by adding the following lines:

deb http://deb.devuan.org/merged daedalus main
deb http://deb.devuan.org/merged daedalus-security main

Then run

# apt-get upate aupdate
# apt-get install --no-install-recommends libncurses5

to get it installed (without including any "recommends" for it).

hth

Note that the alsa configuration for a program is loaded only once, at program start. So a configuration change like that will be in effect for the programs started after the change (only).

There is however a "refer" element that can be used in the configuration, to be expanded upon sink creation rather than just once initially. Your configuration must include such a "refer" element in order to have a configuration change take effect within an already started program.

Yes, Devuan installer ISOs since daedalus have included syslinux bootloaders only.

Quite possibly a Ventoy boot loader fails, especially if the newer versions have lost their syslinux ability, but in any case, Ventoy doesn't present the media as a bootable device so they might not work fully anyhow.

If you make sure that the Ventoy partition is labelled "Ventoy", and is of type exfat, then Devuan's Ventoy patching might kick in to make it work for you.

The "problem" for partitioning tools is probably that for a hybrid ISO, the first partition spans the whole disk, from sector 0 and to the last ISO sector. That span of course includes both the partition table and the second partition.  It also has the additional quirk, that the iso9660 interpretation has a block size of 2048 bytes per block, whereas the disk image view used in particular for the second partition is of 512 bytes per block.

I guess it's not easy for a graphical tool developer team to present and manage that kind of partition overlap which barely is understandable for normal people.

Did you update your copies of the repository meta files first (apt-get update)?

It does sound like you did, and then perhaps something has been removed from debian's pool. I'm not sure the chimaera merge is still happening automatically, so we'll need to check that.

@curranjm, yes, the init programs themselves are not, and should not be, very complicated.

All complexity around "init" comes with the designed/intended framework of the particular init system idea. This is a matter of documenting that framework clearly and openly so that service devlopers can shoe-horn their service control into that framework. The framework itself would be concerned with the ordering of service control activity, and how to detect and handle failure situations. Complex stuff.

I don't think anything much is gained by conflating the complexity of an init framework abstraction with (ideally) the simplicity of the technical operation of an init program.

Are you developing turnstile?

Or "simply" fixing its dinit backend?

I guess I don't understand why you would need to experiment with init systems while fixing the dinit backend for turnstile.

And turnstile in itself should be agnostic about init system.  It merely is a service that implements that concept of "User Services" where a user may set up "services" (programs) to start and restart when and while the user is logged in, and terminate when they log out.

Of course the ABI in detail has that start/restart as a 2-step matter with a "started" notification from the service control scripting separate from progress monitoring, and that's what the backend provides. The backend flavours, to me, only concerns which support utilities for process management would be expected.

But I may well have misunderstood it all. Why is turnstile related to which init system is in use?

You can setup your system to allow hand-picked packages from ceres, by a) pinning ceres packages to something less than 100 and then merely include ceres in your sources.

The pinning would be a file named, say, reluctant-ceres in /etc/apt/preferences.d/ with perhaps the foolwing content:

Package: *
Pin: release n=ceres
Pin-Priority: 90

Adding to sources could be, say, two lines in the file /etc/apt/sources.list with something like the following in it:

deb http://deb.devuan.org/merged ceres main
deb-src http://deb.devuan.org/merged ceres main

Following that preparation, you would first apt-get update and then selectively install by including the desired ceres version code, for example, for that openvpn, you may have:

apt-get install openvpn=2.7.1-1devuan1

The pinning will make it remain so that nothing gets installed from ceres "automatically", ever; including even updates of installed ceres packages. It must all be by hand. If the desired package requires a ceres version of something else, then apt will tell that and refuse installation.

Further, if you want to roll back a ceres package, you again install the package with the desired version code. Doing so will downgrade that package to the indicated version code. Always use apt-cache policy openvpn (or whichever package is concerned) to see which versions you, with your sources, have available for installation (or upgrade or downgrade).

hth, Ralph.

Yes, the convenince!

Don't have to think at all!

Like a commodity, yay!

Who cares what it is? As long as I can just click a button and it just works!

What, Me Worry?

You may need to use setupcon and friends. I guess most convenience support has been done with GUI in mind. Unless you already done it, I suggest you explore man -k keyboard.