Absolut nervige Abhängigkeiten in zypper -- wie abstellen!?
Hallo liebe Leute, openSUSE leap 15.5 Einzig installierter Compiler: gcc12 -- zur C++ Entwicklung Ich entwickele diverse C++ Programme mit dem einzig installierten gcc12. Leider gibt es viele Pakete, die Abhängigkeiten zu gcc7 oder gcc10 haben. Z.B. eine kleine boost-Bibliothek, die mich zwingen wollte, gcc7 zu installieren, nur um sie nutzen zu können, i.e., gegen sie linken zu können. Habe dann letztlich ohne sie gearbeitet. Nun Qt6. Das kleinste der kleinen Hello World Programme verlangt qt6-core- devel. Das Paket hat nun sogar gcc7 _und_ gcc10 installiert. So etwas nervt mich total. Wie kann kann man so etwas abstellen? Es müllt mir die Festplatte unnötigerweise voll. Warum reicht es nicht, ausschließlich gcc12 zu installieren? Hinweis: Ich kompiliere lediglich meine eigenen Programme, nichts von openSUSE 15.5 selbst. Vielen Dank für Eure Hilfe! Viele Grüße Karl
On Dienstag, 3. Oktober 2023 09:52:30 CEST Karl Weber wrote:
So etwas nervt mich total. Wie kann kann man so etwas abstellen? Es müllt mir die Festplatte unnötigerweise voll. Warum reicht es nicht, ausschließlich gcc12 zu installieren?
Was noch mehr nervt: jetzt sind vier gcc Pakete installiert: gcc (system), gcc7, gcc10 und gcc12. gcc nutzt update alternatives, i.e.: ls -l `which g++` lrwxrwxrwx 1 root root 5 Aug 23 2021 /usr/bin/g++ -> g++-7 Allerdings ist es in update alternatives nicht definiert: /usr/sbin/update-alternatives --get-selections | grep gcc zeigt nix. Auch ohne grep gcc finde ich nichts, was zu gcc passt. Also darf ich mir die alternatives jetzt auch noch selbst erzeugen, um den default auf gcc12 zu setzen..... Viele Grüße vom genervten Karl
On Dienstag, 3. Oktober 2023 10:28:30 CEST Karl Weber wrote:
s -l `which g++` lrwxrwxrwx 1 root root 5 Aug 23 2021 /usr/bin/g++ -> g++-7
Zu viel ärgern beeinträchtigt das Denken: Der Link geht natürlich _nicht_ über alternatives :( Bevor also jemand den Finger in diese Wunde legt, habe ich das nun nachgeholt: /usr/sbin/update-alternatives --list gcc /usr/bin/gcc-10 /usr/bin/gcc-12 /usr/bin/gcc-7 ls -l `which g++` lrwxrwxrwx 1 root root 21 Okt 3 10:33 /usr/bin/g++ -> /etc/alternatives/g++ ls -l /etc/alternatives/g++ lrwxrwxrwx 1 root root 15 Okt 3 10:33 /etc/alternatives/g++ -> /usr/bin/g+ +-12 Dazu hatte ich mir vor Urzeiten mal ein Skript erstellt, dass (hoffentlich) alle Binaries von gcc berücksichtigt: #!/bin/bash # # Version 0.1 from 2012-08-1 # if [ $# -le 0 ]; then echo "Need at least one argument" exit -1; fi update-alternatives --install \ /usr/bin/gcc gcc /usr/bin/gcc-${1} ${1} \ --slave /usr/bin/gcc-ar gcc-ar /usr/bin/gcc-ar-${1} \ --slave /usr/bin/gcc-nm gcc-nm /usr/bin/gcc-nm-${1} \ --slave /usr/bin/gcc-ranlib gcc-ranlib /usr/bin/gcc-ranlib-${1} \ --slave /usr/bin/gcov gcov /usr/bin/gcov-${1} \ --slave /usr/bin/gcov-dump gcov-dump /usr/bin/gcov-dump-${1} \ --slave /usr/bin/gcov-tool gcov-tool /usr/bin/gcov-tool-${1} \ --slave /usr/share/man/man1/gcc.1.gz gcc.1.gz /usr/share/man/man1/gcc- ${1}.1.gz \ --slave /usr/share/man/man1/gcov.1.gz gcov.1.gz /usr/share/man/man1/gcov- ${1}.1.gz \ --slave /usr/share/man/man1/gcov-dump.1.gz gcov-dump.1.gz /usr/share/man/ man1/gcov-dump-${1}.1.gz \ --slave /usr/share/man/man1/gcov-tool.1.gz gcov-tool.1.gz /usr/share/man/ man1/gcov-tool-${1}.1.gz \ --slave /usr/bin/g++ g++ /usr/bin/g++-${1} \ --slave /usr/share/man/man1/g++.1.gz g++.1.gz /usr/share/man/man1/g++- ${1}.1.gz Warum fehlt das alles in openSUSE leap 15.5 und den vielen Vorgängen (sonst hätte ich so ein Skript gar nicht), oder bin ich einfach nur zu blind, das zu finden??? Gut, dass ich das Skript hatte, aber das macht in meinen Augen das Defizit nur noch deutlicher und führt zur ursprünglichen Frage zurück, warum kann man nicht mit gcc12 alleine arbeiten, ohne die anderen Versionen installieren zu müssen!? Viele Grüße Karl
Hey, Hast du mal `zypper in/dup` --no-recommends probiert? Je nach Paket kann es aber auch sein das diese -devel Pakete mit neueren Compilern nicht bauen und deswegen ältere Gcc's wollen. Nützlich ist auch in diesem Fall `rpm -v -e --test <Paket-zu-entfernen>`. Mit diesem Kommando kannst du schauen welches Paket <Paket-zu-entfernen> braucht bzw. hineinzieht. -- Grüße, Björn
Hi Björn, On Dienstag, 3. Oktober 2023 12:13:30 CEST Björn Bidar wrote:
Hast du mal `zypper in/dup` --no-recommends probiert? Je nach Paket kann es aber auch sein das diese -devel Pakete mit neueren Compilern nicht bauen und deswegen ältere Gcc's wollen.
--no-recommends kannte ich schon, es hatte keine Auswirkungen, bei keinem meiner bisherigen Versuche :( Die qt6 pakete sind libraries, i.e., elf binaries, die zugehörigen devel Pakete header files und cmake files. Die sollten mit gcc12 genauso gut compiliert und gelinkt werden können, wie mit gcc7, oder nicht!? Ich sehe da überhaupt keine Abhängigkeiten zur Compiler-Version, solange der Compiler neu genug ist. Klar, zu alte Compiler sollten nicht unbedingt funktionieren, wenn die header files neuere, noch nicht unterstützte Sprach-Features beinhalten, aber umgekehrt sehe ich da kein Problem. Ich gehe auch nicht davon aus, dass gcc12 ein anderes ABI hat, als gcc7. Das hätte ich schon längst merken müssen, da ich gegen viele libraries linke. By the way: ich arbeite aktuell durchweg mit -std=c++20, auch das sollte also keine Probleme verursachen können. (Hat es auch noch nicht -- mit gcc12 ;) )
Nützlich ist auch in diesem Fall `rpm -v -e --test <Paket-zu-entfernen>`. Mit diesem Kommando kannst du schauen welches Paket <Paket-zu-entfernen> braucht bzw. hineinzieht.
Das kannte ich noch nicht, und das geht wie folgt: gcc7 wird benötigt von gcc-7-3.9.1.x86_64 gcc-7-3.9.1.x86_64 wird benötigt von gcc-c++-7-3.9.1.x86_64 gcc-c++-7-3.9.1.x86_64 wird benötigt von qt6-base-common- devel-6.4.2-150500.3.7.4.x86_64 Und damit sind wir wieder am Anfang... :( Fast jedenfalls! Seltsamerweise liefert rpm -v -e --test qt6-core-devel nix. Und genau dieses Paket hat den ganzen Rattenschwanz hineingezogen. Hmmmm. Viele Grüße Karl
Hallo Karl, hallo zusammen, Am Dienstag, 3. Oktober 2023, 12:44:26 CEST schrieb Karl Weber:
On Dienstag, 3. Oktober 2023 12:13:30 CEST Björn Bidar wrote:
Nützlich ist auch in diesem Fall `rpm -v -e --test <Paket-zu-entfernen>`. Mit diesem Kommando kannst du schauen welches Paket <Paket-zu-entfernen> braucht bzw. hineinzieht.
Das kannte ich noch nicht, und das geht wie folgt:
gcc7 wird benötigt von gcc-7-3.9.1.x86_64
gcc-7-3.9.1.x86_64 wird benötigt von gcc-c++-7-3.9.1.x86_64
gcc-c++-7-3.9.1.x86_64 wird benötigt von qt6-base-common- devel-6.4.2-150500.3.7.4.x86_64
Du kannst übrigens auch für mehrere Pakete gleichzeitig testen: rpm -e --test paket1 paket2 paket3 Dann werden die Abhängigkeiten zwischen paket1, paket2 und paket3 ausgeblendet (würden ja alle gelöscht) und Du siehst nur Abhängigkeiten zu anderen Paketen.
Seltsamerweise liefert rpm -v -e --test qt6-core-devel nix. Und genau dieses Paket hat den ganzen Rattenschwanz hineingezogen. Hmmmm.
Das ist gar nicht seltsam - qt6-core-devel löschen macht ja nix kaputt, weil z. B. gcc wenig überraschend kein Requires: qt6-core-devel hat. Oder um es als Real-World-Beispiel zu sagen: ("Wasser" ist in diesem Beispiel qt6-core-devel, gcc ist ein "Eimer") - Wasser benötigt einen Eimer - aber: ein Eimer benötigt kein Wasser (kann ja auch leer oder mit etwas anderem gefüllt sein) Daher ist "rpm -e Wasser" problemlos, während "rpm -e Eimer" (hoffentlich) zu einer Fehlermeldung führt. Oder zu einer Pfütze ;-) Wenn Du Dir die Abhängigkeiten mal genauer anschauen willst, gibt es übrigens ein paar rpm-Optionen: rpm -q --requires paket rpm -q --recommends paket rpm -q --suggests paket und in Gegenrichtung: rpm -q --whatrequires symbol rpm -q --whatrecommends symbol rpm -q --whatsuggests symbol "symbol" kann ein Paketname sein, aber auch ein via "Provides:" festgelegter Name. Um diese Namen rauszufinden, hilft rpm -q --provides paket rpm -q --whatprovides symbol That said: die Abhängigkeiten in diesem Fall sind tatsächlich übertrieben und IMHO einen Bugreport wert. Gruß Christian Boltz -- Ja, wirklich! /vpn/../vpns/! Die 90ies haben angerufen, sie wollen ihre Bugs zurückhaben! Und DAFÜR brauchen die über einen Monat zum Fixen. Das, meine Damen und Herren, ist der Grund, wieso es in der IT keine Satire gibt. Die hat keine Chance gegen die Realität. [https://blog.fefe.de/?ts=a0ddd8c1]
On Dienstag, 3. Oktober 2023 23:17:26 CEST Christian Boltz wrote:
That said: die Abhängigkeiten in diesem Fall sind tatsächlich übertrieben und IMHO einen Bugreport wert.
Genau! Wenn Du mir sagst wo (Link) schreibe ich einen. Vielen Dank dafür und das andere davor! Werde ich in meine Dokumentation aufnehmen! Viele Grüße Karl
Hallo Karl, hallo zusammen, Am Mittwoch, 4. Oktober 2023, 12:41:49 CEST schrieb Karl Weber:
On Dienstag, 3. Oktober 2023 23:17:26 CEST Christian Boltz wrote:
That said: die Abhängigkeiten in diesem Fall sind tatsächlich übertrieben und IMHO einen Bugreport wert.
Genau! Wenn Du mir sagst wo (Link) schreibe ich einen.
https://bugzilla.opensuse.org Falls Du erstmal eine Bedienungsanleitung brauchst: https://bugs.opensuse.org/
Vielen Dank dafür und das andere davor! Werde ich in meine Dokumentation aufnehmen!
:-) Noch eine kleine Ergänzung: Es gibt auch Fälle von indirekten Abhängigkeiten, also z. B. xy-devel braucht foo, foo braucht bar, bar braucht gcc. Da musst Du Dich also ggf. ein wenig durch die rpm-Abfragen durchhangeln. Gruß Christian Boltz -- "Da wo ich bin gibt es kein Fax!" "Wo sind sie denn? "2021." [https://nitter.net/isotopp/status/1350204321913319427]
Christian Boltz
Hallo Karl, hallo zusammen,
Am Mittwoch, 4. Oktober 2023, 12:41:49 CEST schrieb Karl Weber:
On Dienstag, 3. Oktober 2023 23:17:26 CEST Christian Boltz wrote:
That said: die Abhängigkeiten in diesem Fall sind tatsächlich übertrieben und IMHO einen Bugreport wert.
Genau! Wenn Du mir sagst wo (Link) schreibe ich einen.
Falls Du erstmal eine Bedienungsanleitung brauchst: https://bugs.opensuse.org/
Ich glaube in diesem Fall liegt es daran das er gcc-7 als default gcc gesetzt hat. qt6-base-common-devel erfordert kein gcc-7. Schau hier: https://build.opensuse.org/projects/KDE:Qt6/packages/qt6-base/repositories/o...
On 06.10.23 08:37, Björn Bidar wrote:
Ich glaube in diesem Fall liegt es daran das er gcc-7 als default gcc gesetzt hat.
qt6-base-common-devel erfordert kein gcc-7.
qt6-base-common-devel erfodert gcc-c++. Was wiederum den gcc nachzieht. Was bei Leap halt nur von gcc-7 bereitgestellt wird. Das ist ja Teil den Problems. Viele Grüße Ulf
On Dienstag, 3. Oktober 2023 09:52:30 CEST Karl Weber wrote:
Nun Qt6. Das kleinste der kleinen Hello World Programme verlangt qt6-core- devel. Das Paket hat nun sogar gcc7 _und_ gcc10 installiert.
So etwas nervt mich total. Wie kann kann man so etwas abstellen? Es müllt mir die Festplatte unnötigerweise voll. Warum reicht es nicht, ausschließlich gcc12 zu installieren?
Noch ein Nachtrag, der das Problem noch deutlicher macht: Ich habe aktuell 20 devel Packete installiert. 18 davon haben keine Abhängigkeit zu einem gcc Compiler, alle entsprechenden libraries und headers konnte ich mit gcc12-only problemlos nutzen. Nur die beiden aktuell installierten qt6 devel Packete ziehen gcc7 und gcc10 hinein. Das war genauso bei der boost Bibliothek, die, soweit ich den Code bisher verstanden habe, noch nicht einmal C++11 voraussetzt, sondern irgendwas wie C+ +98 oder so. Viele Grüße Karl
On 03.10.23 09:52, Karl Weber wrote:
Nun Qt6. Das kleinste der kleinen Hello World Programme verlangt qt6-core- devel. Das Paket hat nun sogar gcc7 _und_ gcc10 installiert.
So etwas nervt mich total. Wie kann kann man so etwas abstellen? Es müllt mir die Festplatte unnötigerweise voll. Warum reicht es nicht, ausschließlich gcc12 zu installieren?
QT6 hat den 12er gcc nicht in der Liste der supporteten Platformen. https://doc.qt.io/qt-6/supported-platforms.html Ob das dennoch funktionieren würde entzieht sich meiner Kenntnis. Wenn Du das abstellen möchtest, wüsste ich keinen Weg außer zypper si qt6-base vim /usr/src/packages/SPECS/qt6-base.spec und neu bauen. Ob sich das für Dich lohnt, kann ich nicht beurteilen. Viele Grüße Ulf
participants (4)
-
Björn Bidar -
Christian Boltz -
Karl Weber -
Ulf Volmer