Legacy-Software unter Debian Buster dauerhaft installieren

[miriquidi]

Hallo allerseits,

ich versuche mich mal wieder am Linux-Umstieg. Beim zweiten Mal auf Standard-Intel-Hardware ist es schon leichter als zuvor, aber es tauchen hier und da neue Probleme auf:
Ich würde gerne unter Debian Buster amd64 das alte Opera 12 installieren.
Jetzt wird das natürlich nicht mehr für Buster angeboten, sondern liegt nur noch unsigniert auf einem Repository bei opera.com. Aber man kann sich ja die "opera_12.16.1860_amd64.deb" einfach händisch herunter laden und händisch installieren. Da es eh keine Updates mehr geben wird, ist das aus meiner Sicht akzeptabel. (Über Sicherheit reden wir jetzt mal nicht...).

Ich bekomme dann folgende Fehlermeldung(en), die mich eigentlich gar nicht weiter stören. Opera läuft trotzdem, weil modernere Versionen der fehlenden Bibliotheken installiert sind und die scheinbar abwärtskompatibel sind.

root@X220:/home/d/Software# PATH=$PATH:/sbin
root@X220:/home/d/Software# dpkg -i opera_12.16.1860_amd64.deb 
Vormals nicht ausgewähltes Paket opera wird gewählt.
(Lese Datenbank ... 138579 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von opera_12.16.1860_amd64.deb ...
Entpacken von opera (12.16.1860) ...
dpkg: Abhängigkeitsprobleme verhindern Konfiguration von opera:
 opera hängt ab von libgstreamer-plugins-base0.10-0 (>= 0.10.16); aber:
  Paket libgstreamer-plugins-base0.10-0 ist nicht installiert.
 opera hängt ab von libgstreamer0.10-0 (>= 0.10.15); aber:
  Paket libgstreamer0.10-0 ist nicht installiert.
 opera hängt ab von gstreamer0.10-plugins-good; aber:
  Paket gstreamer0.10-plugins-good ist nicht installiert.

dpkg: Fehler beim Bearbeiten des Paketes opera (--install):
 Abhängigkeitsprobleme - verbleibt unkonfiguriert
Trigger für man-db (2.8.5-2) werden verarbeitet ...
Trigger für desktop-file-utils (0.23-4) werden verarbeitet ...
Trigger für mime-support (3.62) werden verarbeitet ...
Trigger für hicolor-icon-theme (0.17-2) werden verarbeitet ...
Trigger für shared-mime-info (1.10-1) werden verarbeitet ...
Fehler traten auf beim Bearbeiten von:
 opera

Das Problem tritt beim nächsten Start von Synaptic auf. Es beschwert sich über das defekte Paket "opera" und deinstalliert es jeder Änderung am System (z.B. Sicherheitsupdates, ...) automatisch. Man kann das scheinbar auch nicht über die GUI unterbinden.
Wie kann man denn Debian Buster beibringen, opera als Fremdkörper zu akzeptieren und in Ruhe zu lassen. Ein eine virtuelle Windows-Maschine will ich es jetzt nicht unbedingt verpacken.

 

[mifritscher]

Tipp: mach nach dem ausmisten der sources.list mal ein aptitude search ~o (notfalls aptitude nachinstallieren), dann siehst du Pakete, die von Quellen kommen, die du nicht mehr verwenden willst. Die kannst du dann entsorgen. Erfordert manchmal ein wenig Fingergefühl, weil man da durchaus mal mit dpkg purge --force-all und apt -f install (um dann kaputte Abhängigkeiten aufzufinden und ggf. zu reparieren) machen muss. Grundsatz: Wennn apt -f install viele Pakete deinstallieren möchte sollte man sehr misstrauisch werden In #16 wurde u.a. synaptic deinstalliert.

 

[mcb]

Wenn du das Paket ohnehin nicht mit dem Paketmanager verwalten willst, hier der erste Treffer bei Google:

https://debiananwenderhandbuch.de/debian-pakete-manuell-entpacken.html

Gut funktionierende Paketmanager und fertigen Paketen für alles scheint die Experimentierlust zu lähmen.

Früher war /usr/local und später /opt voll mit selbst geschriebenen oder zumindest selbst kompilierten Software weil die Liste der fertigen Pakete sehr überschaubar war. Jetzt finden sich dort wohl nur einige Shell Skripte. Das heisst aber nicht, dass man da Programme nicht unabhängig von Paketmanagern reinpacken kann.

Auspacken, nach /usr/local/ kopieren, fertig.

Installation mit cp, Deinstallation mit rm -rf.

Kurze Zwichenfrage:

Ich packe alles nach /opt oder in mein Homeverzeichnis.

z.B. geekbench in /opt (Schreibgeschützt für Benutzerkonten)
FirefoxDeveloper in ~ (kann ich dann selbst Aktualisieren)

Wie verhält es sich mit /usr/local ?

Danke.

 

[miriquidi]

Vor der großen Putzaktion werde ich nochmal Backups der Daten des Systems anfertigen. Dauert aber noch etwas.

 

[miriquidi]

Hallo,
ein kurzes Update: Die Datensicherung war eine gute Idee, denn zwischenzeitlich ist das System vermutlich unrettbar hinüber. Irgendwie will XFCE nicht mehr und das Internet zum Nachinstallieren geht auch nicht mehr. R.I.P.

Jetzt habe ich noch eine grundsätzliche Frage, die ich vielleicht hätte vorher stellen sollen: Wie stelle ich denn unter Linux sicher, dass man "alte" Software weiter nutzen kann?

Ich habe bei meinem ersten Versuch (Debian 7) schon gelernt, dass man die Treiber immer wieder an den Kernel/X-Server angepasst werden muss, weshalb mein altes AMD-Notebook leider nicht mehr vernünftig unter Linux läuft (mangels konkurrenzfähigem OpenSource-GPU-Treiber). Das habe ich mit dem Umstieg auf eine Intel-Maschine erledigt.

Aber betrifft das genauso auch die Anwendungssoftware? Über die Jahre entwickelt man ja Vorlieben um bestimmte Aufgaben mit dem Rechner mittels einer Software XYZ effizient zu lösen. Ich bin mal durch mein Windows-Startmenü durchgegangen, und da ist vieles mit mehr als 10 Jahren und einiges mit nunmehr um die 20 Jahre Alter drin. Eigentlich genügen mir diese Programme. Ich kenne mich darin aus, es funktioniert und es hat sehr viel Zeit gekostet, sich darin einzuarbeiten.
Wenn man jetzt diesen Einarbeitungsaufwand für die Debian-Äquivalente treibt, ist denn dann die Nutzbarkeit für die Zukunft garantiert?
Wenn Opera wegen einer alten Compiler-Version nicht läuft, was würde ich dann mit einer z.B. 10 Jahre alten Matlab-Version machen? Das teure Update kaufen?

 

[mcb]

Unter Linux hast du doch die Wahl ob du ein Packet updatest oder nicht. "Anpinnen" in der Packetverwaltung. Einen mehrere Jahre veralteten Browser möchte man ev. nicht nutzen ...

 

[miriquidi]

# deb http://deb.opera.com/opera/ stable non-free

Der Eintrag ist momentan inaktiv, fügt dem System also keinen neuen Schaden mehr zu. Was hier unter Buster passiert ist, als er noch aktiv war lässt sich kaum reproduzieren. Lass den Eintrag weg!
Was mir beim Anschauen der Pakete von dort auffällt ist, dass die offenbar mit gcc-4 gebaut wurden. Schon Stretch hatte gcc-6 und sowohl zwischen gcc-4 und gcc-5, als auch zwischen gcc-5 und gcc-6 gab es ABI-Brüche. Es würde mich also nicht wundern, wenn der Browser unter Buster (gcc-7) nicht laufen oder an beliebigen Stellen abstürzen würde, selbst wenn du die Pakete installiert bekämst.

Hätte man das gleiche Problem nicht auch mit einer anderen fertig compilierten Software (z.B. Matlab), die man vor ~10 Jahren gekauft hätte? Den Quelltext bekommt man ja nicht immer mit dazu.

 

[hikaru]

Hätte man das gleiche Problem nicht auch mit einer anderen fertig compilierten Software (z.B. Matlab), die man vor ~10 Jahren gekauft hätte? Den Quelltext bekommt man ja nicht immer mit dazu.

Ja, das Problem hast du mit jeder Software.
Die übliche Lösung ist, sich den Quellcode zu besorgen, falls nötig auf den neuesten Stand zu bringen, und auf dem aktuellen System neu zu bauen.
Natürlich kann das nicht jeder Nutzer, insbesondere nicht, wenn er keine umfangreiche Programmiererfahrung hat. Deshalb gibt es Distributionen, die diese Aufgabe für den Nutzer übernehmen. Und deshalb sollte man nach Möglichkeit bei den vom Distributor bereitgestellten Paketen bleiben. Manche Fremdquellenanbieter leisten ganz ordentliche Arbeit, indem sie gut an die jeweilige Distribution angepasste Pakete bereitstellen, aber als Nutzer sollte einem dabei bewusst sein, dass das immer mit einem gewissen Risiko verbunden ist. Es gibt schließlich einen Grund, warum der Fremdanbieter seine Pakete nicht im offiziellen Repo der Distribution anbietet.
Einer dieser Gründe kann sein, dass der Fremdanbieter keinen Quellcode anbietet. Damit ist er zumindest für Debian main und contrib disqualifiziert. Und ohne Quellcode kann auch beim besten Willen niemand anderer die Arbeit des Fremdanbieters überrnehmen. Genau das ist dir mt Opera auf die Füße gefallen. Sieh es ein: Opera ist tot!

Unter Windows hast du das Problem übrigens nur deshalb nicht, oder nicht so stark, weil dort sehr lange für solche Zombie-Software auch noch passende Zombie-Umgebungen bereitgestellt werden oder zumindest installierbar sind, die genausowenig Sicherheitsupdates bekommen, wie die Zombie-Software selbst. Das ist übrigens historisch betrachtet eines der großen Sicherheitsprobleme von Windows.
Das Linux-Äquivalent hierzu wären die früher im Thread erwähnten Container-Lösungen, von App-Images bis hin zu VMs - mit den gleichen Sicherheitsproblemen.

 

[miriquidi]

Wobei eine Container / virtuelle Maschine sind ja auch kein Garant für eine dauerhafte Lösung, weil VMware/XZY ja auch einfach den Support für zukünftige Debianversionen einstellen kann. Dann ist der Upgrade-Pfad für das Host-Betriebssystem natürlich pfutsch und die Suche + Einrichterei geht von vorne los.

 

[Gummiente]

Ich glaube in dem Kontext war Docker und KVM, XEN gemeint.

Dass VMware den Support einstellt ist nicht eine Frage von "ob" sondern "wann". VMware hat sich nie darum gekümmert ob ihre Kernelmodule mit einem neueren Kernel bauen lassen oder nicht.

 

[rjm]

Wenn alle fehlende Abhänigkeiten erfüllt werden können, spricht nichts dagegen, Opera 12.16 zu installieren. Dazu kommt, dass etwa Archlinux ein sogenanntes opera-legacy in den repositories bereithält. Ich habe das vor rund einem Jahr mit EndeavourOS getestet.
Etwa parallel hatte ich Linux-Mint bei meinem Thinkpad auf 20.04 geupdated. Es gibt aber seit 18.04 schon Probleme mit den Abhängigkeiten. In einem speziellen Download-Verzeichnis für Libraries (auf meinem Rechner), die für Opera 12.16 benötigt werden, hatte ich für 20.04 eben einige weitere Libs downloaden müssen, die mit dpkg installiert werden. Ich gehe davon aus, dass das im opera-legacy-package (archlinux) in diesem Sinne gelöst wurde.

Ganz neu ist nun bei einem Desktop die Neuinstallation mit Linux MX-21 KDE. Diese Distribution ist Debian-basiert. Hier musste ich soeben auch libjpeg8 händisch installieren. In der Ubuntu package repository ist diese Library unverändert vorhanden; bei Debian aber nicht.

Aktuelle dpkg-Installzeile:
sudo dpkg --install libgstreamer-plugins-base0.10-0_0.10.36-2ubuntu0.2_amd64.deb libgstreamer0.10-0_0.10.36-1.5ubuntu1_amd64.deb gstreamer0.10-plugins-base_0.10.36-2ubuntu0.2_amd64.deb gstreamer0.10-plugins-good_0.10.31-3+nmu4ubuntu2.16.04.3_amd64.deb usrlib/libpng12-0_1.2.54-1ubuntu1.1+1_ppa0_focal_amd64.deb libjpeg8_8c-2ubuntu8_amd64.deb libjpeg-turbo8_2.0.6-0ubuntu2_amd64.deb
(Dateien könnten hier ggf. als tar.gz bereitgestellt werden)

Wenn keine Probleme gemeldet werden, kann opera installiert werden:
sudo dpkg --install opera_12.16.1860_amd64.deb
Läuft jetzt in MX-21.

Hinweis in Sachen Opera-Mail 1.0 (Windows/Wine), aus https://forums.opera.com/topic/14920/opera-mail-for-linux/9:

The standalone Opera Mail is an unfinished and buggy product. It's just Opera 12 with some preferences disabled/hidden, a new importer, and a few UI tweaks to hide the browser parts and make it mail-only.

You can just use the Opera Mail that's built into Opera 12 and add/set the http and https protocols under "advanced -> programs" in preferences if you want links in messages to open up in a certain browser.

Aus diesem Grund ("buggy") habe ich beschlossen, bei Opera 12.16 zu bleiben. Vivaldi 4.x kommt momentan leider auch nicht infrage, weil es Funktionseinschränkungen gibt und weil beim Import unverändert Probleme gemeldet werden.