oh man i know that, got a couple rolls of sheet metal, some 1/8th spools of wire, some lenghts of industrial 4 conductor wire i gotta turn to extension cords one day and a good hold of pvc pipe that i keep telling myself i'll turn into a phone holder for an old tripod and the rest into a recurve bow... and that is just the stuff i've more or less thought about what to do with, then i got a good chunk of half written software i gotta sit down and polish

fun i just so happen to have some useful pieces of code on other scripts in https://github.com/eylles/devuan-scripts/ (check every single one, take every piece of code ya want, it is licensed apache2)

in short is to decide if using sudo, sudo with askpass or pkexec:

  has_tty=""
  if tty | grep -qF -e "dev/tty" -e "dev/pts"; then
    has_tty=1
  fi
  if [ -n "$has_tty" ]; then
    sudo command
  else
    if [ -n "$SUDO_ASKPASS" ]; then
      sudo -A command
    else
      pkexec command
    fi
  fi

the content of $SUDO_ASKPASS is usually some program to read a password from the user, some use dmenu or rofi but both programs advice not to use them for password prompts... on my system i set SUDO_ASKPASS to /usr/bin/ssh-askpass which is provided by the ssh-askpass-gnome package, tho i also got a polkit authentication agent for programs like gparted and the like, on my case i run /usr/lib/policykit-1-gnome/polkit-gnome-authentication-agent-1 as a daemon inside my user session the program is provided by the policykit-1-gnome package.

what services are we speaking of tho? services that are ran as root or their own user, ie the ones in /etc/init.d OR services to run as part of the user session?

if it is the first then it is okay to use update-rc.d for sysvinit, tho for other inits such as runit or open rc it would just be a question of detecting which init system is being used and instead of using update-rc.d use a different command, the machinery inside the wrapper will remain the same just changing update-rc.d for the corresponding command to the init system.

and speaking of, i jumped the gun and cobbled a script that for the time being i'm calling initctl that wraps update-rc.d and service at https://github.com/eylles/devuan-script … er/initctl

for the second case it i already got a solution of sorts that i've been working on for a while now, it still is alpha software, it works but i still have to implement some more features like separating the main session processes (window manager, status bar, etc) from the more secondary processes (compositor, clipboard manager, network applet, blueman, etc...) and adding singleshot type processes as right now it assumes everything is a daemon of sorts, it is implementen in pure posix shell https://github.com/eylles/shed

update-rc.d is a perl script, you can always set up a wrapper around it, my suggestion for a graphical wrapper is to do it in 2 parts, one part a pure shell script that does the job of taking an action (enable disable) and multiple inputs to distribute them to update-rc.d, so that you can do:
wrapper disable cups bluetooth cups-registryd and then inside the script do something like this:

args=""
# while the number of arguments is greater than 0
while [ "$#" -gt 0 ]; do
    case "$1" in
        enable|disable|defaults|remove|defaults-disable)
            action="$1"
            ;;
        *) args="$args $1"
            ;;
    esac
    shift
done

for service in $args; do
    update-rc.d "$service" "$action"
done

then on your GUI frontend with either yad zenity or the program to display menus and create GUIs of your choice you can take multiple inputs from the user and send them with either sudo -A (ensure a SUDO_ASKPASS program is set, i use ssh-askpass-gnome which is linked on /usr/bin/ssh-askpas) or pkexec run the wrapper script, this ensure that you are protecting the enabling|disabling|removal requiring sudo authentication and that you are authenticating only once for a call to the wrapper so that all the services get the action applied to them instead of having to require an authentication per service to be enabled|disbaled.

i've looked some times at the power profiles daemon, if you think it will do the job you want just feed the systemd unit to https://github.com/RosstheRoss/sysd2v and it will output an init-d-script style initscript, you can read more about that framework with man 5 init-d-script

speaking of the power profiles daemon you do have to "manually" change which power profile you want to use, i personally much prefer something more automatic  since i do not like to be thinking about what "profile" i want as i usually want my laptop to respond to
A) power source state, ie: is it running on battery or the AC adapter is connected.
B) the load on the system, the more cpu demanding some task is the higher performance options i want.

for that matter i considered rolling an initscript to use https://github.com/AdnanHodzic/auto-cpufreq but after reading the code it does additional stuff that i don't need and is running on a python interpreter which is not lightweight to say... so i ended up rolling out my own solution which is a very lightweight shellscript that only makes use of very few utilities not to mention can react to the usage of the gamemoderun tool which i use for prioritizing games over other processes when gaming, finally my solution does set some of kernel tunables wihch auto-cpufreq doesn't even touch (tho TLP does set some from what i've seen).
you can grab the latest release tarball from the releases section https://github.com/eylles/afreq.sh and install with a simple sudo make install install-sysv , the daemon is highly configurable tho i have not made a manpage yet, neither does it support pstates for intel or amd tho it is on my list to implement support for those.

okay this is now released software

https://github.com/eylles/zram-service

now i just have to see if i can get it packaged on debian...

still the split to the /usr was something that happened due to technical limitations and turning the /usr sub directories into symlinks should have happened since the time that ext4 became a thing.

then again there are some interesting distros out there like gobo linux that don't even care about the "traditional" unix directory layout as gobo can install multiple concurrent versions of a program by having the program versions in their own directories and only symlink the latest libraries and program versions to the "canonical" file names and locations while the other versions may have their own library versions redirected inside their environment.

to explain it is similar to the mechanism that debian already uses with the linux kernel where you can have multiple kernel version and only the latest version installed is linked to the "canonical" location.

to give a more concrete example, gobo with multiple bash versions:

/Programs/bash/
/Programs/bash/5.2.32/usr/bin/bash
/Programs/bash/4.5.11/usr/bin/bash
/Programs/bash/4.0.2/usr/bin/bash

ls -l /usr/bin
/usr/bin -> /bin

ls -l /usr/bin/bash
/usr/bin/bash -> /Programs/bash/5.2.32/usr/bin/bash

which is not only a neat thing but may even be possible to do something similar with apt but that would probably require a fork of dpkg and a lot of scripting for the symlinks.

usrmerge is not the end of the world tho there are valid critiscisms on the way it is implemented, mainly that the decision was taken to just symlink the directories without consulting with the author of dpkg and how that impacted dpkg, as it may lead to some issues (big may, so far i have not experienced any but could) not to mention taking that decision the way it was taken put a lot more pressure on the dpkg author to figure a way to support the usrmerge scheme fast and without potentially impacting packages, tho a situation arose where packages built for usrmerge systems would not work on non usrmerge systems due to autotools resolving the destination paths in a different manner, personally i do see the benefit of the usrmerge as there is no longer a good reason to make the separation of the directories and it is more compatible with very legacy stuff that had binaries in the "wrong" directory for one reason or another.

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.