Thank you for pointing also out: It is for sure not always fine looking when packages are removed. But trying to keep them here nevertheless alive. Perhaps the python-packages mentioned get better in the future? Or the attack-vectors can be reduced? That's the most common issue: The attack-vectors. And for sure Hyperbola is trying best to deliver a fine toolset, but the biggest attack-vector is just us as users. And as long we are not so many or not in favour with strict principles we are having more problems.

I hope we can get therefore a better surface over all system-landscape. Hyperbola has taken action with the change towards BSD, but there is more and I hope the free and libre community is recognizing possible acting points instead running behind convinient solutions.

Sorry to say but picocrypt will be nevertheless not possible to be added. Just to compare:

https://github.com/HACKERALERT/Picocrypt/tree/main/src

To quote:

And the comparison for gcc-go here: https://go.dev/doc/install/gccgo

To quote:

Container-languages like Go, Rust and others are generic a big problem: Projects using those are not complete when downloading a source-tarball. Some provide linking vendor-libraries. But on a generic level they all want to download further sources at build-time and that is nothing Hyperbola will ever support as this is a big risk for freedom and privacy. It would be needed to check every single dependending package and library for non-free parts.

So far now: We will remove hypervideo and git-snapsign as being unmaintained from the repositories. As said: There is research in the background on how to do something different in that direction. But as noted: YouTube and other platforms comparable are not in any way to be combined with free, libre software. It will be always some kind of compromise when trying to address those platforms and it is one thing to do that throughout the webbrowser and another to use some different external application. Especially to have those in the repositories makes it very complicated and not only from the perspective of packaging. Whenever YouTube or others change their API or ways to access video / audio there is an update needed.

As hypervideo not being updated for a longer period we cannot provide that package here any longer. There will be done something different for sure, but we also cannot package other projects like yt-dlp. It will stay up to an individual choice using those packages in the future. And to be very clear: The "individual choice" is to compile and package something like yt-dlp individual. We won't publish any PKGBUILD here in the forums for that and please don't provide that here as this is not compatible neither with the FSDG nor with our social contract. In detail: To provide the possible access towards video-material yt-dlp or also youtube-dl is using an own JavaScript-implementation and therefore the non-free parts of many platforms in detail. Yes, this depends on individual interpretation to compile and install. So we keep it that way also from now on in regards to those kind of applications and packages!

We will surely provide all parts possible to compile and build alternatives in the repositories.
Also there are some other projects like pytube around for direct usage. As said: There are works and researches around. The major problem is also the sizing itself. In the last days we did many analyzing therefore. The approach to modularize is absolutely fine, but when looking at the lines of code it is quite more. Let alone within yt-dlp the module for YouTube has round about 7000 lines of code: https://github.com/yt-dlp/yt-dlp/blob/m … youtube.py

That's quite the opposite of being small for sure and this is one module. There are more modules and therefore platforms included within those projects. Yes, especially this is making them attractive for sure. But this is making also kind of more as auditing that amount of code is even more complicated. Personally I won't state anyone what to do, but it is surely better to think right away about "streaming" those days. Not only from the technical aspect alone, but that's another topic. Just to show the insights as hypervideo used the same base. A fix would be nevertheless possible if there is interest and also it would be possible to revive the package, when someone is interested to step forward as maintainer.

No, the package xsct was not removed as it was not fully build until now.

No for the moment I don't know about any encrpytion-software in that region. But the python-port was exactly the older version of picocrypt before their migration towards Go.

Then we have a surprise as gkrellm will be part for Hyperbola 0.4.3 in version 2.3.11.

Thanks for noting: The package gnome-dictionary will be removed as there is no usage for that package. For the mentioned link: We cannot add a wrapper for any kind of service as this as a problematic dependency.

Using the wording "bloat" is quite often too much. It is a very wide definition with missing focus often. But for gnome-dictionary there was a solution found and this was a fine downgrade of the package itself with some further patching.

In general: If someone has interest, we need help to implement runit into our cryptsetup-package. And no, it won't help alone just to use a copied file from elsewhere. To note about runit: Yes, using scripts, but every single one has to be fitting exactly all needed input parameters for deamons and services. So for every package every runit-definition is different.

Our main focus for 0.4.3 is not adding so much more packages, but in fact the desktop-experience. So therefore help is appreciated:  https://forums.hyperbola.info/viewtopic.php?id=804

Well, so far correct but nevertheless the definition can also include problems as any kind of project can get to the point where development stucks or people behind have no other possibility as to not care. From outside to look it is always not nice, inside look is a bit different. Therefore I just want to point out that we have to be careful with the wording around. Some applications are small in the outcome but from the codebase very complicated. Others have a simple codebase, but in the outcome being right far big. Others seem to be easy for implementation but carry around a long list of dependencies, even though they seem not having that many in the first place.