[geloest] rpmbuild und Abhaengigkeiten

klaus-dieter · 27 Apr. 2006

Hallo,

wenn man ein rpm installiert gibt es ja schonmal Meldungen der Art "Abhaengiges rpm XYZ fehlt bitte zu erst installieren". Ich habe jetzt ein rpm gebaut welches zum kopilieren jpeglib und exiv2 braucht. Ich kann das rpm aber auch installieren wenn z.B. exiv2 nicht auf dem System vorhanden ist. Wie kann ich dem rpm sagen es soll sich nur installieren wenn die Voraussetzungen a, b, c erfuellt sind?

Woran merkt das rpm beim installieren eigentlich, dass eine Abhaengigkeit nicht erfuellt ist, an der rpm Datenbank? Sprich wenn ich ein abhaengiges Program manuell installiere ist zwar alles da aber rpm meckert immer noch beim installieren?

Danke und Gruss

admine · 27 Apr. 2006

Dafür musst du "Requires" angeben.
Beispiel:

Code:

BuildRequires:	liblo-devel
BuildRequires:	libusb
Requires:       jack >= 0.9
Requires:       libxml2
Requires:       alsa
Requires:       gtk2

BuildRequires: die zum Bauen des RPMs benötigt werden
Requires: die für die Installatin benötigt werden (bzw. damit das Proggi dann funzt

)

Die Angabe macht man im ersten Bereich des Spec-Files, also da wo auch "Name" und "Version" stehen.

traffic · 27 Apr. 2006

admine schrieb:
Dafür musst du "Requires" angeben.

Nein, bitte nicht. rpmbuild erkennt das automatisch.

Gibt man die Abhängigkeiten zusätzlich auch noch explizit an, dann macht das nichts besser, aber einiges komplizierter.

Jochen_r schrieb:
Ich habe jetzt ein rpm gebaut welches zum kopilieren jpeglib und exiv2 braucht. Ich kann das rpm aber auch installieren wenn z.B. exiv2 nicht auf dem System vorhanden ist.

Nein, wenn das so aussieht, dann irrst Du Dich. Prüf bitte noch mal ganz genau nach. Zum Beispiel mit folgendem Befehl:

Code:

rpm -qp --requires PFAD_ZU_DEINEM_RPM.rpm

Wetten, dass alle benötigten Bibliotheken da auftauchen? Ich wette um eine Kiste Deines Lieblings-Getränks.

Sollte die Bibliothek da nicht auftauchen, dann wird sie auch nicht gebraucht - so einfach ist das.

Jochen_r schrieb:
Woran merkt das rpm beim installieren eigentlich, dass eine Abhaengigkeit nicht erfuellt ist, an der rpm Datenbank?

Also: Abhängigkeiten zu Bibliotheken werden schon während des RPM-Baus automatisch erkannt. Dazu verwendet rpmbuild äußerst zuverlässige Tools wie z.B. ldd und objdump. Deswegen sind Abhängigkeiten zu Bibliotheken im Allgemeinen nicht zusätzlich auch noch explizit anzugeben. Tut man es doch, dann riskiert man diverse Probleme wie z.B. falsche Fehlermeldungen, wenn die abhängige Bibliothek in einem RPM mit einem anderen Namen installiert ist.

Es gibt ein paar Ausnahmen, wie z.B. wenn ein Programm eine bestimmte Version einer Bibliothek braucht. So eine Ausnahme ist bei Dir aber garantiert nicht gegeben, weil das letzte Release der libjpeg mehrere Jahre alt ist, d.h. wenn jemand die libjpeg installiert hat, ist die Version garantiert neu genug, und bei exiv2 steckt sowieso die komplette Versionsnummer im Dateinamen der Bibliothek.

Explizit angeben soll man Abhängigkeiten nur, wenn rpmbuild sie nicht automatisch erkennt, z.B. bei Abhängigkeiten zu ausführbaren Dateien (!= Bibliotheken) und zu Perl- oder Python-Modulen.

Jochen_r schrieb:
Sprich wenn ich ein abhaengiges Program manuell installiere ist zwar alles da aber rpm meckert immer noch beim installieren?

An der Stelle würde ich Dich bitten, die Frage nochmal genauer zu stellen, weil ich jetzt gar nicht mehr weiß, wie herum das Problem ist:

(1) Dein selbstgebautes RPM lässt sich installieren, obwohl es sich nicht installieren lassen sollte
(2) Dein selbstgebautes RPM lässt sich nicht installieren, obwohl es sich installieren lassen sollte

admine · 28 Apr. 2006

traffic schrieb:
admine schrieb:

Dafür musst du "Requires" angeben.

Zum Vergrößern anklicken....

Nein, bitte nicht. rpmbuild erkennt das automatisch.

Gibt man die Abhängigkeiten zusätzlich auch noch explizit an, dann macht das nichts besser, aber einiges komplizierter.

Ist es nicht aber so, arbeitet der Packager mit Sorgfalt, weiß der User sofort, welches RPM ihm zur Installation fehlt.
Er erspart doch dem User, welcher das RPM installiert, die Suche nach "in welchem RPM ist denn nun wieder diese lib" z.B. :roll:

Ok ok, dafür gibts dann wieder "pin" ...

traffic · 28 Apr. 2006

admine schrieb:
Ist es nicht aber so, arbeitet der Packager mit Sorgfalt, weiß der User sofort, welches RPM ihm zur Installation fehlt.

Ja, Sorgfalt ist ein gutes Stichwort, aber nicht weil Sorgfalt weiterhilft, sondern um zu zeigen, dass es auch mit Sorgfalt nicht richtig geht.

Als Beispiel: Ziemlich oft findet man in RPMs sowas hier:

Code:

Requires: openssl >= 0.9.6

Dumm nur, dass openssl den Bibliotheksnamen mit jedem Release ändert. D.h. verwendet man openssl 0.9.7, dann ist diese Angabe schon irreführend - sie suggeriert, dass openssl 0.9.6 reichen würde, tut es aber nicht. Wenn aber jemand das RPM gegen openssl 0.9.6 selbst baut, dann reicht es doch wieder. => Mit Sorgfalt kommt man da nicht weit, weil das Ergebnis aus der spec-Datei überhaupt nicht "vorherzusehen" ist.

Automatisch geht es viel besser als mit der bestgemeinten Sorgfalt, da kommt nämlich am Ende sowas bei raus:

Code:

Requires: libssl.so.0.9.6

oder

Code:

Requires: libssl.so.0.9.7

immer passend zu genau der Version, die wirklich gebraucht wird.

Noch viel ekliger ist sowas hier:

Code:

Requires: wxGTK >= 2.4.2

Wenn ich sowas sehe könnte ich echt ausrasten, weil es komplett sinnlos ist. wxGTK verwendet sogar Symbol-Versioning, d.h. es ist niemals notwendig, die Abhängigkeit explizit anzugeben. Stattdessen bereitet eine explizite Angabe nur Probleme, weil es 2 hoch x Möglichkeiten gibt, wxGTK zu konfigurieren (GTK1/GTK2, ANSI/Unicode, Debug/Release etc.), die man mit so einer manuellen Angabe nicht erwischt, die dafür aber ganz zuverlässig automatisch erkannt werden.

Auch sehr beliebt ist sowas hier in 3rd-Party-RPMs für Mandriva:

Code:

Requires: qt >= 3.2

Leider heißt das Qt-3.x-Paket bei SuSE nicht "qt", sondern "qt3". "qt" steht bei SuSE für Qt >= 4.0, bei Mandiva heißt es "qt4". Das hat nichts mit irgendwelchen "Abweichungen vom Standard" zu tun, denn der Standard ist etwas ganz anderes, nämlich:

Code:

Requires: libqt-mt.so.3

für Qt 3.x

bzw.

Code:

Requires: libQtGui.so.4

für Qt >= 4.0.

Funktioniert garantiert immer, ganz ohne Zutun des Verpackers, sowohl mit als auch ohne Sorgfalt.

admine schrieb:
Er erspart doch dem User, welcher das RPM installiert, die Suche nach "in welchem RPM ist denn nun wieder diese lib" z.B. :roll:

Intelligente Paketmanager (apt, smart und wirklich auch das verschriene yast2) installieren die Bibliotheken automatisch mit.

Man muss sich nur einmal das Konzept aneignen, das hinter RPM-Abhängigkeiten steckt. Bei RPM-Abhängigkeiten geht es nicht um Dateinamen oder Paketnamen, sondern um "Capabilities", d.h. "Fähigkeiten". Diese bilden viel besser als hartkodierte Listen ab, was ein Paket tatsächlich braucht oder zur Verfügung stellt.

Probleme gibt es wie gesagt nur, wenn eine bestimmte Version benötigt wird, ohne dass diese aus dem Bibliotheksnamen erkennbar wäre. Dafür bieten die glibc und der ELF-Standard diverse Lösungen an, die aber leider viel zu wenig benutzt werden. In solchen Fällen führt dann leider kein Weg am expliziten Auflisten der Abhängigkeiten vorbei.

klaus-dieter · 28 Apr. 2006

Hi,

kann es sein, dass ich Bibliotheken waehrend des Kompilierens brauche aber spaeter nicht mehr fuer die Laufzeit? Vielleicht ist das was bei mir die Verwirrung verursacht.*

Was den rpm -qp --requries Befehl angeht, dieser listet mir alles moegliche auf, kann ich anstatt der Liste der einzelnen Libs etc auch einen Liste bekommen welche Pakete ich brauche? Angenommen mir fehlt libxyz.so als File, woher weiss ich welches Paket ich auf der DVD / Web suchen muss?

Danke und Gruss,

admine · 28 Apr. 2006

@traffic

Danke für diese gute Erläuterung!

oc2pus · 28 Apr. 2006

@traffic:
wie würdest du dann die libcairo.so.X Problematik lösen ?

es gab mal Zeiten, da wurde die libcairo.so.1 von OpenOffice provided, ein swt von eclipse provided diese library ebenfalls und zu guter letzt das Paket cairo(-devel).

Und da Pakete offensichtlich in der alphabetischen Reihenfolge (wobei OpenOffice, dann gewonnen hat) analysiert werden durch rpm, kam es zu den tollsten Seiteneffekten... d.h. ein Paket welches eigentlich das Paket cairo benötigte, versuchte dann eben mal OpenOffice dafür zu missbrauchen und installierte munter drauf los.

Erst durch die explizite Angabe von "Requires: cairo" bzw konnte dem Spuk ein Ende gemacht werden...

Deshalb habe ich mir angewöhnt alle Pakete die ich zum erstellen brauche in die Requires rein zu schreiben und anschliessend mit dem Tool rpmlint zu prüfen und dann "obsolete" Requires zu entfernen bzw Requires: libXXXX erst gar nicht aufzunehmen.

rpmlint gibt es hier:
http://rpmlint.zarb.org

traffic · 28 Apr. 2006

oc2pus schrieb:
@traffic:
wie würdest du dann die libcairo.so.X Problematik lösen ?

es gab mal Zeiten, da wurde die libcairo.so.1 von OpenOffice provided, ein swt von eclipse provided diese library ebenfalls und zu guter letzt das Paket cairo(-devel).

Ja, das ist dann genau so eine Ausnahme, wo man die Abhängigkeiten explizit angeben muss und soll. Wobei dazu aber auch zu sagen ist, dass das "eigentlich" ein Bug im OpenOffice.org-Paket war, den man auf verschiedenen Wegen lösen kann:

- Keine eigene Kopie von cairo in anderen Paketen, sondern die systemweite Kopie benutzen
- Nicht so früh anfangen, Bibliotheken zu benutzen - cairo war damals noch Beta
- Die "Provides"-Einträge des OpenOffice.org-Pakets nachbearbeiten, damit cairo nicht darin auftaucht
- [...]

Ohne Zugriff aufs OpenOffice.org-Paket kann man das natürlich nicht ändern, deshalb - wie gesagt: Wenn es mal notwendig ist, soll man es machen, aber im allgemeinen finde ich es nicht vorteilhaft.

rpmlint kenne ich. Damit ist es aber auch so eine Sache - es findet nicht alle problematischen Dinge, beispielsweise fehlende Verzeichnisse in der Dateiliste.

Sooo furchtbar schlimm ist es auch nicht, bloß finde ich es einfach übertrieben, alles explizit anzugeben. Ganz konkret bereitet das z.B. Probleme, wenn Pakete anders aufgespalten werden oder wenn sie unter verschiedenen Namen in mehreren Repositories liegen, obwohl sie eigentlich kompatibel wären.

Nur um zu verdeutlichen, weshalb ich wenig davon halte, sich sowas anzugewöhnen: Neulich ist mir mal so ein aMule-Paket untergekommen:

Code:

AutoReqProv: Off
Requires: wxGTK >= 2.4.2
Requires: xorg-x11-libs

Grauenhaft! OK, es ist ein Extrembeispiel, aber: X.org wird nach SuSE 10.1 aufgespalten, das Paket mit der libX11.so.6 wird danach garantiert nicht mehr xorg-x11-libs heißen und die Sache mit wxGTK ist eigentlich ganz klar: So eine Angabe passt auf alle Konfigurationen, aber nur eine, nämlich genau die, die zum Bauen benutzt wurde und automatisch erkannt würde, wird funktionieren.

Jochen_r schrieb:
kann es sein, dass ich Bibliotheken waehrend des Kompilierens brauche aber spaeter nicht mehr fuer die Laufzeit? Vielleicht ist das was bei mir die Verwirrung verursacht.

Hast Du Reveal statisch gegen exiv2 gelinkt? In dem Fall würdest Du die Bibliothek zur Laufzeit nicht brauchen. Ich bezweifle das aber, weil exiv2 standardmäßig eine dynamische Bibliothek braucht.

Such doch mal in der Liste nach libexiv2-0.9.1.so. Und schau auch mal mit ldd nach, ob das Binary gegen die libexiv2-0.9.1.so gelinkt ist. Wenn nicht, dann wurde es statisch gelinkt und braucht die Bibliothek zur Laufzeit nicht.

Jochen_r schrieb:
Was den rpm -qp --requries Befehl angeht, dieser listet mir alles moegliche auf, kann ich anstatt der Liste der einzelnen Libs etc auch einen Liste bekommen welche Pakete ich brauche?

Probier es mal so:

Code:

rpm -qp --requires <Paket> | xargs rpm -q --whatprovides | grep -v "no package" | sort | uniq

Jochen_r schrieb:
Angenommen mir fehlt libxyz.so als File, woher weiss ich welches Paket ich auf der DVD / Web suchen muss?

Sowohl YaST als auch diverse RPM-Suchmaschinen wie http://rpm.pbone.net untertützen die Suche nach "Provides"-Einträgen. Da einfach den Bibliotheksnamen angeben.

apt und smart installieren die Bibliotheken automatisch mit.

klaus-dieter · 28 Apr. 2006

Der etwas laengliche Befehl klappt, genau das was ich gesucht habe, danke.

Tja was das statische linken angeht, keine Ahnung ich habe es uebersetzt und installiert... Sorry kenne mich da nicht so gut aus. :-(
Wie kann ich das rausfinden?

Habe "ldd /usr/bin/Reveal" ausgefuehrt, liefert mir eine Liste von .so Files, libexiv2 ist nicht dabei (aber z.B. libjpeg die auch von ./configure abgefragt wird).

Was sagt mir das jetzt alles?

traffic · 28 Apr. 2006

Jochen_r schrieb:
Der etwas laengliche Befehl klappt, genau das was ich gesucht habe, danke.

Daraus kann man ein Skript machen, dann ist es nicht so lang.

Jochen_r schrieb:
Tja was das statische linken angeht, keine Ahnung ich habe es uebersetzt und installiert... Sorry kenne mich da nicht so gut aus. :-(
Wie kann ich das rausfinden?

Du hast es doch bereits herausgefunden.

Jochen_r schrieb:
Habe "ldd /usr/bin/Reveal" ausgefuehrt, liefert mir eine Liste von .so Files, libexiv2 ist nicht dabei (aber z.B. libjpeg die auch von ./configure abgefragt wird).

Klares Ergebnis: Wenn libexiv2 nicht dabei ist, dann wurde es statisch gelinkt und wird deshalb zur Laufzeit nicht gebraucht.

klaus-dieter · 28 Apr. 2006

okay, bleibt nur die Frage ob das gut oder schlecht ist, ob ich daran was aendern kann oder soll?

Wer legt fest ob was dynamisch oder statis gelinkt ist? Der der die binaries baut oder der Entwickler schon?

traffic · 28 Apr. 2006

Jochen_r schrieb:
okay, bleibt nur die Frage ob das gut oder schlecht ist, ob ich daran was aendern kann oder soll?

"Eigentlich" ist es nicht gut, weil Du in diesem Fall die exiv2-Bibliothek nicht aktualisieren kannst, ohne auch Reveal neu zu kompilieren.

Es hängt allerdings davon ab, was Du haben willst: Wenn außer Reveal kein anderes Programm die exiv2-Bibliothek benutzt, dann spricht das wiederum dafür, sie statisch zu linken. Und der Punkt mit dem Aktualisieren ist in diesem Fall auch nicht wirklich zutreffend, weil die exiv2-Bibliothek ihren Namen mit jedem Release ändert, d.h. Du müsstest Reveal sowieso neu kompilieren.

Jochen_r schrieb:
Wer legt fest ob was dynamisch oder statis gelinkt ist? Der der die binaries baut oder der Entwickler schon?

Das kannst Du direkt beeinflussen. Der Linker wird mit der Option "-lexiv2" angewiesen, nach der Bibliothek in dieser Reihenfolge unter diesen beiden Namen zu suchen:

libexiv2.so
libexiv2.a

".so" ist die dynamische, ".a" ist die statische Bibliothek. Wenn eine dynamische vorhanden ist, wird die dynamische benutzt, ansonsten die statische. Du hast die dynamische Bibliothek aber vermutlich unter diesem Namen installiert:

libexiv2-0.9.1.so

Damit trotzdem die dynamische benutzt wird, musst Du einen entsprechenden Symlink setzen. Eigentlich tut das Makefile von exiv2 das selbst, aber dieser Symlink scheint bei Dir verlorengegangen zu sein.

klaus-dieter · 29 Apr. 2006

okay, habe das Problem gefunden.

Die Exiv Bibliothek habe ich ueber ein selbsterstelltes rpm installiert, dort fehlte der sym link auf die dyn. Bibliothek. Daher ein paar neue Fragen:

1. Wie bekomme ich den Sym Link in das rpm?

2. Wie finde ich alle Sym Links die fehlen?

3. Wenn ich die exiv Libs jetzt dynamisch linke ins reveal, wie soll ich dann angeben das reveal mind. exiv2 0.9.1 braucht? Ist das requires dafuer so ein Fall?

traffic · 29 Apr. 2006

Jochen_r schrieb:
1. Wie bekomme ich den Sym Link in das rpm?

Indem Du ihn in die Dateiliste übernimmst.

Der Symlink wird doch standardmäßig durch "make install" erstellt, aber wenn Du ihn nicht in die Dateiliste nimmst, dann fehlt er im RPM, weil rpmbuild nicht aufgeführte Symlinks ignoriert.

Jochen_r schrieb:
2. Wie finde ich alle Sym Links die fehlen?

Indem Du in $RPM_BUILD_ROOT nachschaust. Entweder mit einem grafischen Dateimanager oder so:

Code:

cd $RPM_BUILD_ROOT
find . -type l

Jochen_r schrieb:
3. Wenn ich die exiv Libs jetzt dynamisch linke ins reveal, wie soll ich dann angeben das reveal mind. exiv2 0.9.1 braucht? Ist das requires dafuer so ein Fall?

Nein!

rpmbuild wird die Abhängigkeit zu dieser Bibliothek automatisch erkennen, und da im Namen der Bibliothek die komplette Versionsnummer sowieso schon steht (libexiv2-0.9.1.so), musst Du nichts extra angeben.

Tust Du es doch, dann schadet das im Moment zwar nicht, aber Du riskierst, dass es Probleme gibt, wenn das exiv2-Paket mal anders aufgespalten ist.

Beispiel: Ich nehme mal an, dass Du ein großes Paket namens "exiv2" hast, in dem alles drin ist. So kann man es machen, man kann es aber auch anders machen. Zum Beispiel könnte man ein Paket namens "exiv2" mit nur dem Kommandozeilenprogramm (/usr/bin/exiv2), ein Paket namens "libexiv2" mit den Bibliotheken (/usr/lib/*.so) und ein Paket "exiv2-devel" mit den Header-Dateien (/usr/include/exiv2) machen. Wenn Du jetzt den Paketnamen hartkodierst, dann würde es nicht mehr zusammenpassen und Du müsstest Dein Reveal-Paket auch noch überarbeiten, obwohl es völlig vermeidbar ist. Und wenn jemand Dein Reveal-Quellpaket rebuildet und es dabei statisch linkt, hätte er eine hartkodierte Abhängigkeit drin, die dann einfach falsch wäre usw.usf. Lass es.

klaus-dieter · 29 Apr. 2006

und schon wieder neue Fragen....

Habe das library Paket jetzt gebaut, installiert und dann das reveal paket gebaut. Funktioniert alles. Nun habe ich zum Test alles deinstalliert und, die library manuell installiert (passiert automatisch in /usr/local/lib anstatt /usr/lib), wenn ich nun versuche das rpm zu installieren sagt er mir er kann die library nicht finden.... Wo ist da was falsch gelaufen? Einer der Entwickler was vergessen? Ich beim bauen was vergessen? Beim mir auf dem System was falsch?

Was die Versionen angeht nochmal eine Frage. Ich brauche mind. exiv2 0.9.1 was z.Zt. die neuste Version ist, kann also nichts testen ob es mit einer neueren laeuft. Egal ob rpm -qp --requries oder ldd /usr/bin/Reveal zeigt mir das libexiv2-0.9.1.so gebraucht wird - ich haette erwartet libexiv2.so. Was ist nun wenn ich (in Zukunft) mal eine Version 0.9.2 installiert habe?

traffic · 30 Apr. 2006

Jochen_r schrieb:
Nun habe ich zum Test alles deinstalliert und, die library manuell installiert (passiert automatisch in /usr/local/lib anstatt /usr/lib), wenn ich nun versuche das rpm zu installieren sagt er mir er kann die library nicht finden.... Wo ist da was falsch gelaufen? Einer der Entwickler was vergessen?

Nein, genau so soll das sein! RPMs und manuell installierte Software kann man nicht vermischen, weil RPMs ihre Abhängigkeits-Infos in eine Datenbank eintragen. Bei der Installation anderer RPMs werden diese wieder aus genau dieser Datenbank ausgelesen, nicht aus dem installierten System, deswegen können nur RPMs die Abhängigkeiten anderer RPMs erfüllen.

Das ist normal und gewollt, Deine Beobachtung deutet also nicht auf ein Problem hin.

Jochen_r schrieb:
Was die Versionen angeht nochmal eine Frage. Ich brauche mind. exiv2 0.9.1 [...]

Nein, Du brauchst nicht "mindestens" 0.9.1, sondern genau 0.9.1.

Jochen_r schrieb:
[...] kann also nichts testen ob es mit einer neueren laeuft.

Das brauchst Du nicht zu testen, es wird nicht laufen. Ist doch auch klar: Wenn der Name der Bibliothek libexiv2-$VERSION.so lautet, dann brauchen die abhängigen Programme auch genau $VERSION - weder niedrigere noch höhere Versionen werden funktionieren.

Jochen_r schrieb:
Egal ob rpm -qp --requries oder ldd /usr/bin/Reveal zeigt mir das libexiv2-0.9.1.so gebraucht wird - ich haette erwartet libexiv2.so.

Da muss ich wohl doch etwas weiter ausholen.

Jede Bibliothek ist unter mindestens zwei Namen verfügbar: Einem, der die Versionsnummer enthält und einem, der die Versionsnummer nicht enthält. Diese beiden Namen dienen völlig unterschiedlichen Zwecken.

Der Name ohne Versionsnummer (libexiv2.so) dient dazu, die Bibliothek beim Bauen zu finden. An dieser Stelle wird ein Name ohne Versionsnummer verwendet, damit man mit einem Makefile alle Versionen abdecken kann und das Makefile nicht für jede neue Version anpassen muss. Beachte bitte, dass die "2" keine Versionsnummer, sondern Bestandteil des Namens ist.

Der Name mit Versionsnummer (libexiv2-0.9.1.so) dient dazu, die Bibliothek zur Laufzeit zu finden. An dieser Stelle wird ein Name mit Versionsnummer verwendet, damit man mehrere, möglicherweise inkompatible Versionen gleichzeitig installieren kann, die von fertig kompilierten Programmen benutzt werden können.

Und jetzt kommt das Fiese an der Geschichte: exiv2 folgt leider einer Unsitte, für die Bibliothek kein eigenes Versionsschema zu verwenden, sondern die komplette Versionsnummer des Pakets zur Versionsnummer der Bibliothek zu verwenden:

libexiv2.so
libexiv2-0.9.1.so

Der "wirkliche" Standard sieht aber ganz anders aus, da hat man nämlich nicht zwei Namen, sondern gleich drei:

libqt-mt.so
libqt-mt.so.3
libqt-mt.so.3.3.4

Bei diesem Schema ist der Name ohne Versionsnummer auch derjenige, der zur Bauzeit benutzt wird, der mit der langen Versionsnummer ist der wirkliche Dateiname der Bibliothek und der mit der kurzen Versionsnummer ist noch ein Symlink, der zur Laufzeit benutzt wird.

Das hat den Vorteil, dass die Versionen

libqt-mt.so.3.3.0
libqt-mt.so.3.3.1
libqt-mt.so.3.3.2
libqt-mt.so.3.3.3
libqt-mt.so.3.3.4
libqt-mt.so.3.3.5

vollständig kompatibel und austauschbar sind, weil der Name, der zur Laufzeit benutzt wird, in jedem Fall

libqt-mt.so.3

lautet. Leider folgt exiv2 diesem sehr bewährten Schema nicht, was sehr bedauerlich ist.

Jochen_r schrieb:
Was ist nun wenn ich (in Zukunft) mal eine Version 0.9.2 installiert habe?

Dann wirst Du Reveal für die neue exiv2-Version auch wieder neu kompilieren müssen - alternativ könntest Du den Autor von exiv2 kontaktieren und ihn bitten, ein wenig auf Binärkompatibilität zu achten... :roll:

[geloest] rpmbuild und Abhaengigkeiten

klaus-dieter

Hacker

admine

Ultimate Guru

traffic

Guru

admine

Ultimate Guru

traffic

Guru

klaus-dieter

Hacker

admine

Ultimate Guru

oc2pus

Ultimate Guru

traffic

Guru

klaus-dieter

Hacker

traffic

Guru

klaus-dieter

Hacker

traffic

Guru

klaus-dieter

Hacker

traffic

Guru

klaus-dieter

Hacker

traffic

Guru