daemon is on the repos and i will say is a good solution all things considered.

regardless i'm still working on this: https://github.com/eylles/shed with the goal of perhaps having a release this month.

there are 2 alternatives that ARE in debian and devuan without messing with outdated packages.

one is to use an askpass frontend for sudo, sudo with the -A flag will launch a helper program to get the user password, i've seen even rofi used for that purpose (mind you the author recomends to NOT use rofi for sudo askpass) but a good package for that is ssh-askpass-gnome (gtk frontend), then simply put this line on your .profile export SUDO_ASKPASS="/usr/bin/ssh-askpass"

two is to use pkexec with some polkit authentication agent, most desktop environments have their own polkit agent autostarted but if your's doesn't or you use a window manager then the package policykit-1-gnome provides a gtk polkit auth agent, the autostart desktop file specifies it as gnome only iirc, but you can add your own autostart entry in ~/.config/autostart or simply run /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 somewhere in your .xsession.

the package is on unstable, https://tracker.debian.org/pkg/scrcpy

with elogind you should not need sudo to run loginctl hibernate, tho nowadays i use suspend-then-hibernate, and configure logind so that 30 minutes after suspend-then-hibernate the laptop shuts down for hibernation, i find that more useful than either suspend or hibernate as if it is on StH for less than 30 mins i get practically instant resume, but for more than that it saves battery.

what is the problem? it should add just like any other repo, if it is for the part of the script where it uses lsb_release just use the debian suite name i guess.

well, necroposting side, it doesn't seem like there would be complication to the plan of using the systemd sources to build an 'egummyboot' after rolling a shim that provides the functionality of kernel install, at least so long as the upstream systemd-boot does NOT integrate the libraries and utilities of systemd more into it's own code beyond the level of simply calling their named binaries for the function, tho still i will say for as simple as that seems it almost feels like there's a foot gun waiting to happen there...

i do personally use pipewire and it works for what i do, which is using software that relies on pulse while using software that relies on jack, last i checked that was still a set of hoops to jump with pulse and jack, but since pipewire can provide the interfaces for both pulse and jack from the same daemon it is just a matter of simply running any DAW or plugboard and it just works.

sudo should not be used on init scripts, not directly because of security, but it is assumed not every system may had sudo installed as a minimal install with a root account and password will only have su and require running su to change into the root account to perform all administrative tasks.

that aside in a proper initscript the variable RUN_AS_USER is defined, usually as RUN_AS_USER=root for daemons intended to be ran by the root user, for daemons that need to be ran under a specific user the variable is defined with the intended user.

accordingly the start-stop-daemon program will be used to guarantee correct behaviour, ie check for initialization of instance and creation of the pid file.

an example standar use of start-stop-daemon would be as follows:

start-stop-daemon -S --pidfile ${PIDFILE} --make-pidfile --background \
            --chuid ${RUN_AS_USER} --startas ${DAEMON} -- ${DAEMON_ARGS}

as for the options straight from the manual:

-S, --start [--] arguments
           Check  for  the existence of a specified process.  If such a process exists, start-stop-daemon does nothing, and exits with error status 1 (0 if --oknodo is specified).  If such a process does not exist, it
           starts an instance, using either the executable specified by --exec or, if specified, by --startas.  Any arguments given after -- on the command line are passed unmodified to the program being started.

the flags and the vars passed should be descriptive enough and those are expected to be defined earlier on the initscript.

as for --background it is used with prgrams that will not fork to background by themselves.

if you want an okay example of a proper initscript file for an arbitrary daemon check https://github.com/eylles/afreq.sh
the file acpufreq.is is the definition of the initscrip, mind you that when you write initscript files not every daemon will support options like reloading the configuration so the route that many initscripts take is to just have the restart idiom also match reload and force-reload like so:

    restart|reload|force-reload)
        $0 stop && sleep 3 && $0 start
        ;;

took a look at the pipewire setup, left a suggestion in an issue.

honestly as sad as it may seem the devuan forum is not a good place to get feedback on software you are writing on principle of barely getting feedback for one reason or another.

in march i had to move from devuan unstable to testing because the t64 migration wasn't kind to my system and i needed some extra time running as i was, i really want to avoid a re-install but seems like that is what i will have to do.

weird i installed usrmerge back in at least march and everything works, then again i'm on ceres so maybe the usrmerge is more "volatile" on stable but still nothing has broke, as for the argument about uptimes it ain't weird when i clock about 70 days of uptime, the only thing that i've ever noticed not working is the plugin scripts of krita but i never tried using them before the usrmerge so as far as i'm concerned krita on debian is slightly broken and may as well have been forever broken.