Next packages to be removed:

lwm
vtwm
planner

For tabble: https://www.rillion.net/tabble/help.html

Also to note: It is absolute senseless to patch out non-free parts from projects, just to package them with one concrete version. The next release will conclude again with non-free parts to be removed. So Hyperbola will not conclude with packages to remove non-free parts as done in the past.

It is quite simple: When a package and upstream project is not oriented on free, libre culture, it will be removed without any further warning. It is clear and strict. Doing patches for building, for FHS-compliance and more, that is one thing and absolute okay. But patching out non-free parts growing? Not done any longer. Those packages are put on hold and stale either or removed when really no other solution is in reach.

Recommending the wiki-artcle: https://wiki.hyperbola.info/doku.php?id … e_packages
We list therefore for a reason the packages being removed or on hold.

We are living with the results of the assumption that neverending upgrades and additions of features are more helpful than making software persisting, secure and just helpful. So Hyperbola is the opposite of this paradigm and this also means that we will discuss the removal of vulkan at a time. It is one thing of not supported possible features for graphics, another one to redefine all already possible and leaving hardware marked as "no longer supported". This is creating an impossible situation for us all and our environment. Technical innovations with persisting software, not with endless more requirements, endless more dependencies, endless more additions generic. That's not what Hyperbola has made its own course with. We want a minimalistic approach, including also technical emancipation and innovattions at a time.

Next to be removed:

vulkan-headers
vulkan-icd-loader
vulkan-intel
vulkan-radeon
vulkan-mesa-layers
vulkan-validation-layers

Reasoning for Radeon should be clear: Without non-free firmware-blobs there is also no further usage. Nevertheless vulkan adds even more complexity we do not need for the moment. A way was found to restructure and reshape mesa without having further problems and therefore nothing will be changed for real as most packages have already no vulkan-support enabled or even got it removed long before.

I will keep this updated when the new PKGBUILD for mesa is there to be viewed on. And yes: It will be very shortened and so following the idea of minimalism. We should be honest with ourself: Vulkan sounds nice so far, but real support is only unfolded with newer hardware and therefore again an issue Hyperbola points out with economic bloated. Also for this reason we have put some packages like "supertuxkart" on hold: Vulkan is clearly NOT following free and libre community-orientation, otherwise shaderc would not be part of newer releases.

We are working on the following packages sidewise:

zathura (finally adding)
xonotic (getting an update and rework)
darkplaces (possible new addition as 3D-engine)

We are also enhancing xenocara just a bit as there is an addition with editres we'd like to take into.

Simple but clear said: zathura was now again evaluated and we found ways to build that package without the problematic dependencies. So that's most the problem for many others: Most of the reasonable packages are there, but then there are big issues with one or two additional ones. That was the same for zathura. But to say: Building is not the same alike working. So for the moment it just builds and ends with success in a package.

Hyperbola is not only adding and also intense testing afterwards. So when the resulting package is also working fine, we can finally add it. As stated: "We are working on that" not "we are adding it now".

Also to explain in that case what dependency was here the point: It was texlive and libsynctex as resulting library. The first runs about 1,5 years ago for zathura were done under other circumstances and knowledge-base. This has changed and now I was able to circumvent the texlive-issue also as the project-website is stating that this is not really needed. Nevertheless I'm thinking to report upstream that their build-parameters should be a bit reordered making it a bit more clear how to build without texlive. I hope this helps to understand better now! And zathura is clearly oriented minimalist, so leaving it was from the beginning a decision we would like to have corrected.

When the run-tests for zathura going successful, we are going to add it as usual. If the package and application is not running, we do not see need adding it. And we do not see gtk for example as awkward dependency.

It is surely to understand that everybody has a different vision and perspective, but one last point: Please let's work together on Hyperbola. If there are critical points about zathura, add them. To point on a new article in our wiki: https://wiki.hyperbola.info/doku.php?id … ble_system

So that's the dependency-tree for zathura on Hyperbola:

    desktop-file-utils
    file
    girara
    sqlite
    zathura-cb (optional) - Comic book support
    zathura-djvu (optional) - DjVu support
    zathura-pdf-poppler (optional) - PDF support using Poppler
    zathura-ps (optional) - PostScript support
    appstream-glib (make)
    check (make)
    meson (make)
    ninja (make)
    python-sphinx (make)

The package girara is the only one being added and it has same way no dependency further added, all is there. And zathura is same way ported: https://openports.pl/path/textproc/zathura/core

We do not want to go for a sovereignty of interpretation what "software freedom" and "minimalism" should be. And the meaning of "personal freedom" has always to be seen in the relation of "freedom of others" same way. So if people in IRC make a rational discussion about zathura as possible addition and the project is not going against our guidelines, we evaluate for sure any time again. Just that we do not want to add uncountable more packages as said since 0.4.3.