Virtualbox unter Buster (Debian 10)

[geier22]

Ich hab mal eine Frage wegen des ja anstehenden Release - Wechsels:
Ich benutze schon immer Testing und das soll auch so bleiben. Virtualbox ist ja nun nicht mehr in den Repos enthalten. Hat mich aber bisher nicht weiter gestört, da ich immer von Hand installiere,
Bisher gab es ja auf virtualbox.org/ eine Stretch- Version, die auch bei mir immer zufriedenstellen funktionierte.
Jedoch wurde diese Version erst ziemlich lange nach dem Release von Jessie eingestellt.
Nach dem Release und der Umstellung auf Buster hatte ich vor, erst mal die Virtualbox zu deinstallieren, um Probleme und
Inkompatibilitäten zu vermeiden Aber was dann ?
Es gibt auf der Download Seite eine Version

Code: Alles auswählen

All distributions (built on EL5 and therefore do not require recent system libraries)

Datei: VirtualBox-5.1.22-115126-Linux_amd64.run

Ich habe jedoch keine Ahnung, was das built on EL5 bedeutet.
Habe nur das gefunden:

EL5 stands for Enterprise Linux 5 (Red Hat Enterprise Linux version or CentOS version)

Vielleicht hat ja jemand eine Erklärung dafür, und warum das unter Debian laufen sollte?

[KP97]

Du kannst doch weiterhin die Version für Debian 9 nehmen. Ich habe Sid im Einsatz und habe immer die angebotene aktuelle Version für Debian genommen.
Damit gab es nie Probleme. Die EL5 Version ist aber uralt, RHL ist doch bei 7, die gibt es ja auch. Du weißt aber, daß diese Distro rpm-basiert ist?
Bleib bei .deb, da machst Du nichts falsch.

[geier22]

Hallo KP97,
erst mal eine gute Nachricht, dass es mit der Stretch- Version keine Probleme geben dürfte. Danke dafür.
Trotzdem verstehe ich dieses andere Paket nicht ganz:

All distributions (built on EL5 and therefore do not require recent system libraries

Virtualbox installiert ja Kernel-Module, die bei der normalen Installation mit dkms gebildet werden.
Diese "*.run" Datei muss ja also das irgendwie auch tun.
Sonst wäre es ja eine Art snap oder flatpak Paket.
Es gibt ja inzwischen viele mehr oder weniger "unabhängige" Programme die man nur in ein eigenes Verzeichnis entpacken muss,
und sich nicht weiter über das System verteilen. (wie z,B. Firefox/Thunderbird v. Mozilla, TV-Broswer und FreeFileSync, um nur einige zu nennen).
Der große Vorteil, wenn man sie nach /opt/ entpackt:
Ich setze ein neues System auf, und kopiere das gesamte /opt/ in das neue, kreiere eine Paar Starter und gut ist.

Das kann ich mir bei Kernel-Modulen aber kaum vorstellen. Deshalb meine Frage. wie das wohl funktioniert, ohne Abhängigkeiten
zu nennen.
Wenn ich mich mal im Kompilieren versucht habe, zog das in der Regel einen ganzen Schwanz von *.dev -Paketen nach sich,
die für den jeweiligen Compiler bzw. für die Kompilierung gebraucht wurden. Oder es ging gar nicht mehr, weil es die eine oder andere lib in der
verlangten Version nicht mehr gab-->Abbruch.

Deshalb war meine Frage auch, wie das bei einem 10 Jahre alten Kernel (2.6.18) von EL5 funktionieren soll.

[KP97]

Da muß ich passen, aber probier es doch einfach mal aus. Aber wenn, dann mit der Version 7, die EL5 ist definitiv zu alt.
Ich selbst bin vor einiger Zeit auf aqemu umgestiegen, daher will ich momentan keine Vbox installieren.

[owl102]

Du weißt aber, daß diese Distro rpm-basiert ist?

Na und? Ich sehe da die Relevanz nicht, solange es sich bei der Version nicht um ein rpm-Paket handelt. (Ich denke ".run" ist ein Shell Script mit eingebetteten Dateien, genauso wie übrigens auch VMware ihren Player für Linux vertreibt.)

Virtualbox installiert ja Kernel-Module, die bei der normalen Installation mit dkms gebildet werden.

Nein, seit Version 5.1 verwendet VirtualBox kein dkms mehr, sondern baut die Module "on demand". Das ist aber in diesem Zusammenhang ebenfalls irrelevant.

Diese "*.run" Datei muss ja also das irgendwie auch tun.
Sonst wäre es ja eine Art snap oder flatpak Paket.

Wieso sollte ein Shell Script keine Kernel Module bauen können? Ich sehe da kein Problem.

Wenn ich mich mal im Kompilieren versucht habe, zog das in der Regel einen ganzen Schwanz von *.dev -Paketen nach sich,

Das ist ja hier auch so, die Kernel-Module von VirtualBox werden übersetzt, und hierfür sind installierte C-Compiler, die Kernel-Header usw. notwendig. Aber auch hier gibt es keinen Zusammenhang, denn auch das ist so-oder-so der Fall, egal ob ".deb" oder ".run". (Bei ".deb" werden allerdings diese Abhängigkeiten automatisch mitinstalliert, beim ".run" muß man selber dafür sorgen, das notwendige vorab installiert zu haben.)

Deshalb war meine Frage auch, wie das bei einem 10 Jahre alten Kernel (2.6.18) von EL5 funktionieren soll.

Irgendwie ist da ein Knoten in deinem Gehirn. (Aber den bekommen wir schon gelöst.) Was hat der Kernel von RHEL 5 hier für eine Relevanz? In dem Paket stecken natürlich die aktuellen Quellen der Kernel-Module (wie in dem ".deb" auch), und die Kernel-Module kann VirtualBox sowohl unter einem RHEL 5 als auch unter einem aktuellen Debian erfolgreich übersetzen.

Das "EL5" bezieht sich doch nur auf das Binary von VirtualBox, es wurde hier unter RHEL 5 gebaut. Also auf einem recht alten System, was die Wahrscheinlichkeit erhöht, daß die benötigten Bibliotheken (Qt, ...) abwärtskompatibel vorhanden sind, sofern man es auf einem Linux installiert, welches neuer als EL5 ist.

[towo]

Ich sehe das Problem nicht!
1. die *.run ist kein Shell-Script, das ist ein binary installer
2. die *.run sollte man tunlichst nicht auf einem System mit Paketmanagement verwenden
3. die Stretch Pakete funktionieren problemlos auf unstable
4. sobald Stretch released wurde, gibts auch wieder Pakete für testing von oracle, welche auch immer mit unstable funktioniert.

[owl102]

Ich sehe das Problem nicht!

Da sind wir schon zwei.

1. die *.run ist kein Shell-Script, das ist ein binary installer

Code: Alles auswählen

#!/bin/sh
# This script was generated using Makeself 2.1.5

CRCsum="4034031892"
MD5="dfd12f9145328b68191e32bf175e1a16"
TMPROOT=${TMPDIR:=/tmp}

label="VirtualBox for Linux installation"
script="./install.sh"
scriptargs="$0 1> /dev/null"
targetdir="install"
filesizes="87900160"
keep=n

...

Also für mich zumindest sieht das nach einem Shell Script aus...

[towo]

Dann ist es eben ein Script, hat aber auf einem Debian trotzdem nix verloren, wie jedes andere Programm auch, welches man am Paketmanagement vorbei installiert.

[owl102]

Dann ist es eben ein Script, hat aber auf einem Debian trotzdem nix verloren, wie jedes andere Programm auch, welches man am Paketmanagement vorbei installiert.

Daß ein Debian-Paket zu bevorzugen ist, ist IMHO selbstverständlich und brauchen wir daher nicht zu diskutieren. (Und in diesem Falle gibt es ja ein funktionierendes Debian-Paket.)

"Hat auf einem Debian nichts verloren" halte ich aber als generelle Aussage für diskussionswürdig, denn was macht man mit Anwendungen, für die es kein Debian-Paket gibt, wie z.B. AFAIK den VMware Player? (AFAIK gibt es da auch keinen Paketbauer, so wie java-package für das Oracle Java, welches von Oracle selber nicht als Debian-Paket bereitgestellt wird.)

[towo]

Wenn man sowas installieren will, muß man sich eben im Klaren sein, was man sich damit antut.
Hier gehts aber um VBox und da gibts ein Deb, warum also sollte man zu dem generischen Installer greifen?

[KP97]

@owl102
Ich habe geier22 nur daran erinnert, daß es sich bei RHL um ein rpm-Paketmanagement handelt und es daher nicht notwendig ist, solch einen Installer zu nutzen, wenn es .deb Pakete gibt.
Ganz genau so, wie @towo es auch schreibt. Wenn man es denn unbedingt will, kann man ja den Installer nutzen, aber man sollte auch genau wissen, was man da tut (wie eigentlich bei allem).
Aber niemand hat kategorisch .rpm abgelehnt.
Ich zitiere mich mal selbst:

Du weißt aber, daß diese Distro rpm-basiert ist?
Bleib bei .deb, da machst Du nichts falsch.