#appimage

5 posts · Last used Jul 10

Zur Installation von #Software stehen unter Linux seit jeher verschiedene Möglichkeiten zur Verfügung. So gibt es beispielsiwese immer die Möglichkeit der manuellen Übersetzung mithilfe des altbekannten Dreisatzes (configure, make, make install) - inklusive allen Vor- und Nachteilen. Am komfortabelsten ist es jedoch, den jeweiligen Paket-Manager der Distribution zu verweden. So sparen sich User das lästige Übersetzen von Quellcode - doch auch hier gibt es zahlreiche Vertreter. Neben den üblichen Red Hat- (yum, dnf) und Debian-artigen (apt, apt-get) Paket-Managern gibt es noch zahlreiche weitere Tools - und genau hier liegt das Problem. Mit #AppImage, #Flatpak und #Snap gibt es drei weitere Entwicklungen, die es sich zur Aufgabe gemacht haben, Software-Verwaltung unter #Linux zu revolutionieren - doch wie gut gelingt das? cstan.io/post/2021/12/appimage…
0
0
0
0
The #AppImage "packaging" approach being embraced by many projects is just another poor approach. It does not really solve what it is expected to should solve: Dependency issues. More and more .AppImage downloads now produce results like these: /tmp/.mount_tumpa-Z5HMuu/usr/python/bin/python3: error while loading shared libraries: libcrypt.so.1: cannot open shared object file: No such file or directory /tmp/.mount_activiXYBUA0/aw-qt: symbol lookup error: /tmp/.mount_activiXYBUA0/libQt6WaylandClient.so.6: undefined symbol: wl_proxy_marshal_flags I dunno if it is due to incorrect packaging or a design artefact with AppImage. I believe #flatpak is the only true sane way to go. At least if you don't want to frustrate users. #linux #foss #opensource #packaging
1
5
0
0
You've seen all posts