VirtualBox 5.2.18 benötigt libcurl3

[Hanisch]

Hallo,
die Installation von VirtualBox 5.2.18 schlug fehl, weil 'libcurl4' installiert war und sich nicht mit der von VirtualBox 5.2.18 benötigten 'libcurl3' vertrug.
Ich mußte 'ibcurl4' deinstallieren und dann konnte ich 'libcurl3' und VirtualBox 5.2.18 erst erfolgreich installieren.
Wie ist dieses Paket 'libcurl4' ins System gekommen?

Gruß
Ch. Hanisch

[jure]

kann ich nicht bestätigen

Code: [Select]

apt policy libcurl4 virtualbox
libcurl4:
  Installiert:           7.61.0-1
  Installationskandidat: 7.61.0-1
  Versionstabelle:
 *** 7.61.0-1 500
        500 http://httpredir.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
virtualbox:
  Installiert:           5.2.18-dfsg-2
  Installationskandidat: 5.2.18-dfsg-2
  Versionstabelle:
 *** 5.2.18-dfsg-2 500
        500 http://httpredir.debian.org/debian unstable/contrib amd64 Packages

[der_bud]

Hier ebenfalls kein Problem, libcurl4 und libcurl3-gnutls parallel installiert, meine Virtualbox will letzteres. Und ins System kommen libs weil Pakete sie brauchen und daher mitinstallieren. Tipp: Foren-/Internetsuche nach 'aptitude why'

[absolut]

wenn ich das richtig sehe, spricht Hanisch hier über virtualbox-5.2 direkt von der virtualbox.org-repository und nicht von debian. ich nutze auch das paket direkt von virtualbox.org und kann das verhalten reproduzieren:

Code: [Select]

root@sidbox:[~]# apt install virtualbox-5.2
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Einige Pakete konnten nicht installiert werden. Das kann bedeuten, dass
Sie eine unmögliche Situation angefordert haben oder, wenn Sie die
Unstable-Distribution verwenden, dass einige erforderliche Pakete noch
nicht erstellt wurden oder Incoming noch nicht verlassen haben.
Die folgenden Informationen helfen Ihnen vielleicht, die Situation zu lösen:

Die folgenden Pakete haben unerfüllte Abhängigkeiten:
 virtualbox-5.2 : Hängt ab von: libcurl3 (>= 7.16.2) soll aber nicht installiert werden
                  Empfiehlt: libsdl-ttf2.0-0 soll aber nicht installiert werden
                  Empfiehlt: linux-image ist aber nicht installierbar
E: Probleme können nicht korrigiert werden, Sie haben zurückgehaltene defekte Pakete.
root@sidbox:[~]# apt policy virtualbox-5.2
virtualbox-5.2:
  Installiert:           5.2.14-123301~Debian~stretch
  Installationskandidat: 5.2.18-124319~Debian~stretch
  Versionstabelle:
     5.2.18-124319~Debian~stretch 500
        500 http://download.virtualbox.org/virtualbox/debian stretch/contrib amd64 Packages
 *** 5.2.14-123301~Debian~stretch 100
        100 /var/lib/dpkg/status


[melmarker]

ich nutze auch das paket direkt von virtualbox.org und kann das verhalten reproduzieren:

Und das wird sich auch auf ewig™ nicht ändern - wenn man das umgehen will, dann möchte man das bionic-Paket installieren. Wodurch man sich im Falle des Falles niedliche Probleme in der Zukunft™ einhandelt. Hatte ich erwähnt, dass es nicht sonderlich clever ist, Pakete, die für Ubuntu gebaut wurden, unter Sid einzusetzen?

[cryptosteve]

Hatte ich erwähnt, dass es nicht sonderlich clever ist, Pakete, die für Ubuntu gebaut wurden, unter Sid einzusetzen?

Noch nie ... 

[axt]

Mal davon abgesehen, daß es auch noch Testbuilds und Dev-Snapshots gibt,die durchaus Probleme lösen (aber natürlich auch zusätzliche bringen) können, kann man auch VirtualBox*Linux*.run verwenden, gerade auch dann, fährt man unterschiedliche Systeme und will nicht alles mehrfach ziehen. Man muß freilich damit umgehen können.

Also noch mehr Verhunzmöglichkeiten für den Mixer.

[Hanisch]

Hallo,

Also noch mehr Verhunzmöglichkeiten für den Mixer.

Ich benutze seit jeher immer VirtualBox von der Oracle-Homepage und auch die zugehörigen GuestAdditions von der Oracle-ISO, wenn die Distro-eigenen nicht funktionieren.

Code: [Select]

~/DOWNLOADS$ sudo dpkg -i  ~/DOWNLOADS/virtualbox-5.2_5.2.18-124319~Debian~stretch_amd64.debDeshalb habe ich auch:

Code: [Select]

~$ apt policy libcurl4 virtualbox
libcurl4:
  Installiert:           (keine)
  Installationskandidat: 7.61.0-1
  Versionstabelle:
     7.61.0-1 500
        500 http://deb.debian.org/debian unstable/main amd64 Packages
virtualbox:
  Installiert:           (keine)
  Installationskandidat: 5.2.18-dfsg-2
  Versionstabelle:
     5.2.18-dfsg-2 500
        500 http://deb.debian.org/debian unstable/contrib amd64 PackagesInstalliert ist bei mir:
libcurl3  und libcurl3-gnutls
Damit läuft es jetzt einwandfrei.

Um den Vorwurf des Mixens zu entkräften habe ich statt der VirtualBox von der Oracle-Homepage nun aus den Debian/Siduction-Repos folgendes via 'synaptic' installiert:

Code: [Select]

virtualbox
virtualbox-qt
virtualbox-dkms
virtualbox-ext-pack
virtualbox-guest-additions-iso
libcurl3-gnutls
libcurl4

Code: [Select]

~$ apt policy libcurl3-gnutls libcurl4 virtualbox
libcurl3-gnutls:
  Installiert:           7.61.0-1
  Installationskandidat: 7.61.0-1
  Versionstabelle:
 *** 7.61.0-1 500
        500 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
libcurl4:
  Installiert:           7.61.0-1
  Installationskandidat: 7.61.0-1
  Versionstabelle:
 *** 7.61.0-1 500
        500 http://deb.debian.org/debian unstable/main amd64 Packages
        100 /var/lib/dpkg/status
virtualbox:
  Installiert:           5.2.18-dfsg-2
  Installationskandidat: 5.2.18-dfsg-2
  Versionstabelle:
 *** 5.2.18-dfsg-2 500
        500 http://deb.debian.org/debian unstable/contrib amd64 Packages
        100 /var/lib/dpkg/status
Ist das nun besser als die Installation von der Oracle-Homepage?

Gruß
Ch. Hanisch

[melmarker]

Die Pakete von virtualbox,org sind halt "anders" - und die funktionieren eigentlich auch immer ohne Probleme mit der Distribution, für die sie gebaut sind. Erm, nun ja - es gibt da keinerlei Pakete für Testing oder Sid. Das heisst in klar und  deutlich: Wenn sich was Elementares in Sid oder Testing ändert - zum Beispiel ein so-name einer Bibliothek - dann ist man mit diesen Paketen gar mächtig am Arsch.

Nun könnte man libcurl3 -> libcurl4 einfach ignorieren - ist aber nicht ganz so einfach, weil libcurl3 und libcurl4 nicht co-installierbar sind. Das würde in meinem System dazu führen:

Code: [Select]

% sudo apt install libcurl3                                          :(
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut.       
Statusinformationen werden eingelesen.... Fertig
Die folgenden Pakete wurden automatisch installiert und werden nicht mehr benötigt:
  librhash0 yudit-common
Verwenden Sie »sudo apt autoremove«, um sie zu entfernen.
Die folgenden Pakete werden ENTFERNT:
  cmake curl feh gimp-gmic gmic libcurl4 libcurl4-openssl-dev liblxqt0-dev
  lxqt-build-tools simple-paste
Mag für einen anderen User, der auf die Pakete verzichten kann, kein Problem sein - nur ich könnte dann nix mehr entwickeln und das fänd ich nicht wirklich gut.

[Hanisch]

Hallo,

Mag für einen anderen User, der auf die Pakete verzichten kann, kein Problem sein - nur ich könnte dann nix mehr entwickeln und das fänd ich nicht wirklich gut.

Was meinst Du, liege ich jetzt mit meiner Entscheidung gegen die VirtualBox von der Oracle-Homepage besser?

Gruß
Ch. Hanisch

[melmarker]

Kein Wort ohne meinen Anwalt - also ein klares jein, es gibt da folgende Szenarien:
* solange das debian-paket funktioniert, ist alles fein
* solange das oracle-Paket funktioniert, ist alles fein.

In der Natur von siduction liegt es, dass wir manchmal der {Debian-/Oracle-}Zeit voraus sind. Das führt dazu, dass das eine, das andere oder noch besser beide Pakete nicht funktionieren. Und ab da wird es dann witzig.

Situation heute:
* In Sid ist nur noch libcurl4 - das debian-Paket baut dagegen - an der Stelle alles in Ordnung. Es sieht so aus, dass die Module mit dkms und unseren Kernelheadern kooperieren (auch nicht selbstverständlich), wenn jetzt X noch tut (in Abhängigkeit von der Version, auch nicht selbstverständlich), ist erst mal alles in Ordnung.

* Virtualbox.org (stretch): Paket wird für Stretch gebraten - für Stretch werden sie auch wunderbar funktionieren, hängen aber leider von libcurl3 ab - doof, weil das nicht mehr in Sid ist. Resultat: Siehe mein Post. Zustand von X weiss ich momentan nicht. Kernelheader dito - weil ich nicht mal in die Verlegenheit komme, das installieren zu können.

* Virtualbox.org (bionic): Paket wird für Bionic gebraten - ok, zumindest ist es gegen libcurl4 gebaut - letztendlich hatte ich wohl Probleme mit neuem X, wenn ich mich recht erinnere.

* Virtualbox.org(.run) - keine Ahnung und auch keinerlei Lust, das zu ändern.

Spassig an der Sache ist eigenlich nur, dass wir durchaus Pakete für Vbox bereitstellen könnten - und aber aus reinem Selbstschutz dagegen entschieden haben. Wir haben einfach nicht die Manpower und sich auch nicht wirklich so masochistisch veranlagt, uns damit auf Dauer auseinanderzusetzen - zumal es meist sehr ordentlich funktionierende Alternativen wie KVM gibt.



(Nur als Anmerkung, dass die Pakete ab und zu mal für mehre oder weniger lange Zeit Schrott sind, liegt in der Natur der Sache, da gibt es auch nicht wirklich viel, was wir tun können oder wollen)

[melmarker]

Nicht dass wir uns missverstehen - ich hab nichts gegen Virtualbox, wenn es irgendwie funktioniert - da ich das aber nur zum Testen unserer ISOs vor Releases nutze, ist mir in der Zwischenzeit der Zustand von Vbox recht egal. Es ist halt schön, wenn interessierte User unsere ISOs mit Vbox testen können. Wenn das nicht funktioniert - ok, nicht schön, aber auch nicht tragisch. Unstable-User sollten sich zu helfen wissen, wenn nicht - ok, die Gefahr besteht, dass diese Nutzergruppe dann auch nicht mit siduction an sich glücklich wird. In allen stabilen Umgebungen funktioniert Virtualbox eigentlich fein - Wer also auf Windows runterlädt, sollte mit unseren Images spielen können, dito für alle stabilen Distributionen.

Und wenn alle Stricke reisssen - KVM nehmen und einen Blick über den Tellerrand werfen. Dito für Windows - es gibt mehr als eine Applikation, die Virtualisierung anbietet.

[absolut]

hi melmarker,

danke für die vielen detailinfos!

mein Einsatzzweck für virtualbox seit Jahren ist überschaubar mit folgenden Punkten:
- Steuererklärung-Software
- Logitech Universalfernbedienung programmieren (hier wichtig: USB durchreichen)

Nun schau ich mir jetzt mal an, ob es kurzfristig, wie von dir beschrieben, mit virtualbox von debian funzt. Wenn nicht, mach ich einen schritt Richtung KVM.

grüße
absolut

---

Nachtrag, ich habe virtualbox aus debian installiert, scheinbar ohne probleme.

Code: [Select]

root@sidbox:[~]# uname -a
Linux sidbox 4.18.5-towo.1-siduction-amd64 #1 SMP siduction 4.18-5 (2018-08-24) x86_64 GNU/Linux
root@sidbox:[~]# dpkg -l | grep virtualbox
ii  virtualbox                                    5.2.18-dfsg-2                           amd64        x86 virtualization solution - base binaries
ii  virtualbox-dkms                               5.2.18-dfsg-2                           all          x86 virtualization solution - kernel module sources for dkms
ii  virtualbox-ext-pack                           5.2.18-1                                all          extra capabilities for VirtualBox, downloader.
ii  virtualbox-qt                                 5.2.18-dfsg-2                           amd64        x86 virtualization solution - Qt based user interface


[melmarker]

hi absolut - virtualbox ist hier das beste Beispiel, was mit unstable gemeint ist - wenn es läuft, läuft es nur, wenn sich was ändert, gibts Probleme

[axt]

Um den Vorwurf des Mixens zu entkräften

Das ist ein Fakt, bewiesen durch unzählige Threads von Dir zum Thema. Aber schön, daß Du über das Stöckchen springst.

Denke mal darüber nach, wieso Dir eine Ausgabe

virtualbox-5.2:
  Installiert:           5.2.14-123301~Debian~stretch
  Installationskandidat: 5.2.18-124319~Debian~stretch

bei Deinem nicht-stretch nicht zu denken gibt! melmarker hat's Dir ja ausführlich erklärt.

Btw., Du hast ja nicht mal 5.2.16 installiert. Keine Systempflege.

Es bleibt Dir genannte .run-Installation. Daß vorher eine .deb-Installation sauber zu entfernen ist, auch ein darunter ggf. installiertes ExtPack, falls Du wieder zurück willst, die .run-Installation, muß ich dazu sagen?