just to provide more context on the problems you mention:

the licensing is the licensing of the COMPILER, rustc, not the language syntax itself, and yes the license of the compiler does seems a bit in bad faith, but for that there is a project implementing a rust compiler over gcc https://github.com/Rust-GCC/gccrs , it still is a work in progress but the project is already on the stage of compiling the rust stable core library and focusing on increasing coverage of the testsuite.

the ubuntu fiasco with the rust core utilities project, uutils, stems not from the uutils project itself but rather from the ubuntu developers whom decided to ship as default a core utils package whose compatibility level is not just lower than busybox but even right now is not able to pass the gnu coreutils testsuite, so for credit where it is due and blame where it causes shame, this is fault of the ubuntu developers rushing to push a not ready for production package into a "production ready" release as a default core component

that context provided, there is the posibility that the addition of rust into apt could be a very rushed one seeing that the push does come from an ubuntu developer tho beyond that there is nothing else i can comment on a technical level at the time.

makes sense, if anything it should install the policykit-1-gnome as that does provide the polkit-1-auth-agent that would integrate the best with gtk and the network-manager-applet, however my guess is that apt resolved the dependencies getting a list of which packages provide polkit-1-auth and choose the first available option by alphabetical order, were the lxqt agent not available it would had gone with the mate agent...

edit: i just noticed that the policykit-1-gnome agent was removed in trixie because it is unmaintained upstream as stated here https://bugs.debian.org/cgi-bin/bugrepo … bug=990271

so the real solution is to install the mate-polkit-bin package as that WILL integrate with a mainly gtk environment without pulling the lxqt session NOR the mate-session package

unless someone (probably not from the forum), forks and continues the work of stlwrt to have a toolkit library compatible with gtk2 to gtk4 with whichever rendering appearance is desired all that complaining about qt6, gtk4 and the eventually upcoming qt7 and gtk5 will accomplish is to have a bunch of written complains in our corner of the internet

stlwrt: https://github.com/thesquash/stlwrt
ubuntu mate forum thread (where stlwrt repo got posted): https://ubuntu-mate.community/t/horribl … 4/22028/63

posted that from phone and autocorrect screwed me over, forgot to turn that off in this phone lol

ah yes i can explain why even when the ubuntu patch does remove the Client Side Decorations no Server Side Decorations are added, the EWMH and _MOTIF_WM_HINTS, to be more precise the MWM_DECOR_TITLE hint which when set requests the window manager to NOT add titlebars (Server Side Decorations) to a window be it because the window is of type dialog or some other reason like having Client Side Decorations, the ubuntu patch manages to disable the Client Side Decorations on gtk4 but fails to set the appropriate window hints to allow the window manager to decorate the window with a titlebar, if you got a configurable window manager that is a non issue as ya can simply set the window manager to ignore the title hint for gtk4 apps.

for example on greenjames suggestion of using a CSS hack to hide window buttons on gtk4 apps and then just add decorations through the window manager selectively ignoring the title hints of gtk4 apps.

some reference from the hand of awesome wm documentation:
https://awesomewm.org/doc/api/classes/c … o_titlebar

there was a talk a while ago about forking the systemd-boot outta the systemd source tree as egummy-boot for the whole reason that for it to work completely free of any systemd tree untility it just needs a shim, the reason for the fork being to ensure that it remains requiring only that one shim instead of relaying on other systmed "utilities"

edit: the link of the thread https://dev1galaxy.org/viewtopic.php?id=6095

in usual dev1 forum fashion the idea of a shim was discussed along the idea of maintaining a fork to ensure just the shim is needed but the proposal got no traction and nothing was done.

Is not just a decrease in competency, but also a problem of the "entry cost" for the knowledge and the knowledge not being passed along in an efficient manner, case in point is debian packaging, to anyone who wants to package some piece of software for use in debian (and derivates) the whole debian packaging process will seem like some sort arcane magic burdened by bureaucracy after reading the debian maintainer guide once...

redgreen925 do ya use a desktop environment like mate, xfce, kde, etc... or have a setup with a plain window manager and tools composed on top of it?

it could be that for all of use whom get the files piled up is because we are using plain window managers that do not purge their active dbus session address file upon session end (logoff, shutdown, reboot)

eh offtopic but not more offtopic than many of the other posts

https://felipec.wordpress.com/2024/04/0 … -insanity/

autohell truly is the piece of software that keeps on giving, because simple makefiles are poison i guess...

another option would be to cobble a script with yad for the gui (lighter for setups that already use yad) and on the inside all it does is run apt-get commands to show the information of the .deb and installs it with apt-get install <full/path/to/package.deb>

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.