apt is a "work in progress" interactive tool, it has undocumented options (if you don't read the manual) since they may not be tested enough to have full documentation, for example for apt 2.9.6devuan1

       edit-sources (work-in-progress)
           edit-sources lets you edit your sources.list(5) files in your preferred text editor
           while also providing basic sanity checks.

       showsrc, depends, rdepends, policy (summarised in apt-cache(8))

       source, build-dep, download, changelog, clean, distclean, autoclean (summarised in apt-
       get(8))

SCRIPT USAGE AND DIFFERENCES FROM OTHER APT TOOLS
       The apt(8) commandline is designed as an end-user tool and it may change behavior between
       versions. While it tries not to break backward compatibility this is not guaranteed either
       if a change seems beneficial for interactive use.

       All features of apt(8) are available in dedicated APT tools like apt-get(8) and apt-cache(8)
       as well.  apt(8) just changes the default value of some options (see apt.conf(5) and
       specifically the Binary scope). So you should prefer using these commands (potentially with
       some additional options enabled) in your scripts as they keep backward compatibility as much
       as possible.

SEE ALSO
       apt-get(8), apt-cache(8), sources.list(5), apt.conf(5), apt-config(8), apt-patterns(7), The
       APT User's guide in /usr/share/doc/apt-doc/, apt_preferences(5), the APT Howto.

it is testing, usually devuan lags behind debian releases anywhere from weeks to months testing that stuff works and sometimes having to rebuild programs or even fork them to remove the hard dependencies on systemd, it is a "is ready when is ready" type of situation.

well, technically in the keybinds overrides you could do something like this:

     │ ! keybind overrides
     │ UXTerm*VT100.Translations: #override \
     │     Prior <KeyPress>:scroll-back(1,halfpage) \n\
     │     Next <KeyPress>:scroll-forw(1,halfpage) \n\
     │     Shift <KeyPress> Insert: insert-selection(CLIPBOARD) \
     │     Ctrl Shift <Key>V:    insert-selection(CLIPBOARD) \
     │     Ctrl Shift <Key>C:    copy-selection(CLIPBOARD) \

which would work and make the xterm buffer scroll up and down with just the next and prior key, but that is going to cause problems with the tui programs like vim that map functions to the next and prior keys, say in vim instead of scrolling in the vim buffer you'll scroll the xterm buffer which will also show terminal history... and that is without mentioning that you have to unmap the default xterm keybinds that add the half page scroll function cuz otherwise you just duplicated the same function without a keychord for a worse user experience...

    ! xterm default keybinds, see full list with man xterm
        Shift <KeyPress> Prior:scroll-back(1,halfpage) \n\
        Shift <KeyPress> Next:scroll-forw(1,halfpage) \n\

any specific feature that makes it a "worth installing right now" over waiting for it to be added onto either debian or devuan experimental for your daily driver? cuz for testing environments and providing feedback onto the project i do consider an install now if you can spare a "testing machine"

well, more shell slop crudely typed by my hands, this time a handful of scripts that aim to wrap neovim and a terminal emulator into a makeshift gnvim program to better integrate with GUI programs and desktop environments

https://github.com/eylles/xterm-nvim

will try to create a .deb package for it tho.

Anyway, more on topic, password management really has got me thinking for a while that there is not a real "good" generic way to do password management on a unix like environment, seeing all the threads about complains on password managers like keepass, local secre/password access stuff via gnome-keyring-daemon, and browser/mobile password management where the only good solution is bitwarden as you can host your own server and there are at least 3 implementations of the bitwarden server, not to mention the need for OTP codes and all the problems that the gnome-authenticator package had at one point being removed from testing and how difficult it was for the maintainers to package the newer version of the project after it was rewritten from scratch in rust because the rust model of managing it's own dependencies with cargo has a lot of friction with how packages are built in debian...

All that to say, i've been thinking of looking into writing a set of programs for addressing that madness:

• password-keyring-daemon: a daemon to replace the secret store functionality of the gnome-keyring-daemon,will however not provide d-bus functionality by default, all the actual storing of secrets and passwords would be done with pass as a pluggable backend, so whoever doesn't like pass can roll his own password manager and backend wrapper to be used with this daemon.

• password-keyring-daemon-dbus-plugin: an optional plugin for said daemon to add the d-bus functionality for those who need it, this would include the org.freedesktop.secrets portal interface.

• password-bw-imexporter: a plugin to import-export to/from bitwarden, would use a config file to set the bitwarden server and account credentials so users can still self host bitwarden, the idea is to allow the daemon to fetch the passwords csv, merge with the local password store through the backend and then get a merged csv from the backend to export onto the bitwarden server, this would be one of the pieces of this whole set with network access to sync the password stores.

• password-keyring-favicon-fetcher: just a "dumb" program to fetch the favicons, the second program of this set to have net code and would serve to prevent the need of net access in the other programs.

• password-keyring-authenticator-lib: a library to handle all the OTP stuff, not something that would directly be called by the daemon.

• password-keyring-authenticator: a gui program to manage OTP authentication, be it just copy the OTP code to clipboard or add a new authentication entry be it by qr code image or a token.

• password-keyring-manager-lib: a thin client library to retrieve passwords from the password-keyring daemon, to be used by a gui program.

• password-keyring-manager: a gui program to actually manage the locally stored passwords, if the favicon fetcher is present it will show favicons, if the bw-imexporter is present will sync the password store on start and upon changes.

consider those names as placeholders, and for the actual development i would probably use python to have a fast development cycle as besides the very core daemon none of the other programs are "performance critical" to NEED be written in C, and even then re-writing the daemon in C would be something to consider for the time when everything else is working good enouhg..

Tho i got no timeframe whatsoever to do any of this, nor it is for sure i will with my history of starting cobbling together daemons and other programs then taking forever to add basic features...

if you don't like where linux is headed then write software to help prevent that path or at the very least keep the existing path running

the madness of initscripts was/is that they allow for daemons to have subpar behaviour that is abstracted from the init system, and systemd was "sold" as the solution as it could handle some of those badly behaved daemons that needed complex initscripts which were "hard to debug", but developers managed to defeat that idea and re-invent initscripts in a worse language. here's an extract from a conversation i had on this a while ago, should probably put it in my github along other stuff from my vimwiki or use some static site generator to make a blog of sorts

in the unix world we have services and daemons, while many equate "services" with running a web server (or ftp server, or ssh server) of some sort, a "service" in the unix world is not a web server, but just a process that is managed, started, stopped and maybe even monitored by another process.
a daemon is a "long running process", could be one that runs for as long as a user is logged in or for a long as the computer is on, but in spite of daemons mostly being services, they aren't always services, and services aren't always necessarely daemons
there are 2 basic types of services from which all others are but variations of:

daemon: the most basic type of service as it is just a daemon that will run, it can run for multiple runlevels or it can run for as long as a user is logged in, it has a process identification digit (PID), a PID file, it runs with the priviledges of some user, the PID file can be used to monitor the service.

oneshot: a process that will be ran and not linger nor have a PID, it will run, do something and then terminate, maybe with an exit status, whatever command is ran to "start" the service can have a "stop" counterpart, or not.

the "traditional" manner to handle that madness was with initscripts, which are nothing more than just shell scripts that can accept the "start", "stop", "status", "restart" and optionally the "reload" and "force-reload" arguments, the init system needs not to know how the initscript handles those as whatever madness and witchcraft is needed to get the service running is done in the initscript
most inits use the initscript or a similar paradigm of abstracting the sorcery from the init system

systemd has the units system, the paradigm is that the madness is not necessary to abstract from systemd and can be thrown into the multiple options of the systemd unit so long as the systemd unit options can handle said madness... the main options are:
ExecStartPre=
ExecStart=
ExecStartPost=
ExecStopPre=
ExecStop=
ExecStopPost=
ExecReloadPre=
ExecReload=
ExecReloadPost=

now there is nothing bad with those, systemd allows you to just write commands in there and it will evaluate said commands to run them
and then ya got stuff like this, because systemd had to allow multi line commands in some way, and what better and more natural way than to do so with shell style line breaks
ExecReload=busctl call org.freedesktop.DBus \
        /org/freedesktop/DBus org.freedesktop.DBus \
        ReloadConfig
until now there is nothing bad in how units are defined
but that applies for simple commands
the problem starts when people start to abuse the systemd units and treat them like a fully fledged shell-like scripting language just because the documentation says you can throw some madness into the unit file
and you wound up with systemd unit files which are over 50 lines long where at least 40 of those lines are some Exec*Pre/Exec*Post command that juggles values to and from tmp files...

at that point it is just re-inventing initscripts but with a way worse "scripting" language that only got support for a form of conditionals in version 243...
and then someone comes in with some sense to put all that madness of pre and post exec commands inside scripts...
which was what the paradigm that systemd was trying to prevent from happening in the first place because "initscripts are hard to debug" (if you don't know bash)

so the proper way would be to split the initscript to multiple scripts handling start, stop, restart etc. respectively and the define then unit using these scripts?

not really, the "proper" way would be that services should not need much wizardry to be started and stopped, but since that ain't happening... then the less bad way would be to have a (or multiple) script(s) to handle the madness needed by the service and then let both .service unit files and initscripts for whatever init needs them be "dumb" files that deal only with an abstracted and simple interface with a predictable behaviour

yes, apt-get is intended to be the stable APT interface intended to be used in scripts while apt is understood to be the interactive friendly and ever changing interface.

i liked your metadata viewer but did some modifications

#!/bin/sh

# Name: metaview
# Copyleft: greenjeans 2025, use as you see fit.
# This script when combined with a .desktop file, 
# is to give you a "view metadata" option for a given file 
# when you right click on audio/video files in the file manager.
# Depends: ffmpeg, yad, libimage-exiftool-perl

c=0
sep="_"
separator="$sep"
while [ "$c" -lt 80 ]; do
    separator="${separator}${sep}"
    c=$(( c + 1 ))
done

# basename? we don't need that!
filename="${1##*/}"

thumbnail="preview-file"

encode_thumbnail () {
    filepath=$(realpath "$1")
    # ah perl, what would we do without ya and what can we do with ya...
    perl -MURI::file -MDigest::MD5=md5_hex \
        -e 'printf "%s.png\n", md5_hex(URI::file->new(shift))' "$filepath"
}

find_thumbnail () {
    thumbdir="${XDG_CACHE_HOME:-$HOME/.cache}/thumbnails/normal"
    thumbpath=$(encode_thumbnail "$1")
    thumbpath="$thumbdir/$thumbpath"
    if [ -r "$thumbpath" ]; then
        thumbnail="$thumbpath"
    fi
}

find_thumbnail "$1"

# no idea if this will work on a multi-display setup
geometry=$(xdpyinfo | grep 'dimensions:' | cut -d' ' -f7)
w="${geometry%x*}"
h="${geometry#*x}"
w=$(( w - 400 ))
h=$(( h - 200 ))

{
  printf '\n---- %s ----\n' "Metadata for $filename"
  printf '\n%s\n\n' "$separator"
  printf '\n---- %s ----\n' "FFprobe"
  ffprobe -hide_banner "$1" 2>&1
  printf '\n%s\n\n' "$separator"
  exiftool -a -u -g1 "$1"
} | yad \
    --text-info --borders=10 --title="Metadata" --width="$w" --height="$h" \
    --center --window-icon=preview-file --image="$thumbnail" --margins=10 \
    --button=gtk-close:0

the changes are:
make the underline separators 80 columns wide
show the thumbnail of the file if it exists
make the window size depend on the display geometr

he is become browser, the viewer of websites