Mageia Forum

Hallo,

eine Frage zum Paketbau: Wie beschreibt man Abhängigkeiten zum Bauen von 64-bit-Paketen?
Folgendes Problem: Ich möchte das Paket jmtpfs bauen, zum kompilieren der 64-bit-Version braucht das

Code: Alles auswählen

lib64fuse-devel-2.9.2-2.mga3.x86_64   
lib64magic-devel-5.12-8.mga3.x86_64   
lib64mtp-devel-1.1.6-1.mga3.x86_64     
lib64usb1.0-devel-1.0.14-2.mga3.x86_64

Folgende Varianten funktionieren nicht:

Code: Alles auswählen

BuildRequires:  lib%{_arch}usb1.0-devel
Fehler: Fehlgeschlagene Paket-Abhängigkeiten:
        libx86_64usb1.0-devel wird benötigt von jmtpfs-0.4-1.x86_64

BuildRequires:  libusb1.0-devel
Fehler: Fehlgeschlagene Paket-Abhängigkeiten:
        libusb1.0-devel wird benötigt von jmtpfs-0.4-1.x86_64


Das geht, ist aber sicher nicht richtig

Code: Alles auswählen

BuildRequires:  lib64usb1.0-devel

Also die Frage: Wie macht man das richtig?

Grüße,
Lutz

Hallo,

kaum macht man's richtig, schon geht's...

Code: Alles auswählen

BuildRequires:  usb1.0-devel

Grüße,
Lutz

Siehe dazu https://wiki.mageia.org/en/Packaging_gu ... ldRequires

Am Besten die Provides-Tags des jeweiligen Paketes nehmen, und ein automatisch generiertes nehmen.

Code: Alles auswählen

[doktor5000@localhost ~]$ rpm -q --provides lib64usb1.0-devel
libusb1-devel = 1.0.14
libusbx-devel = 1.0.14
usb1-devel = 1.0.14
usb1.0-devel = 1.0.14
lib64usb1.0-devel = 1.0.14-2.mga3
lib64usb1.0-devel(x86-64) = 1.0.14-2.mga3
pkgconfig(libusb-1.0) = 1.0.14
devel(libusb-1.0(64bit))
[doktor5000@localhost ~]$

Ich würde pkgconfig(libusb-1.0) vorschlagen.

Hallo,

d.h. für alle, die eine pc-Datei dabeihaben (z.B. /usr/lib64/pkgconfig/libusb-1.0.pc)? Und ist pkgconfig dann selber ein BuildRequire?

Grüße,
Lutz

Richtig, und pkgconfig ist kein BuildRequire, der Provides-Tag, den du als Buildrequire angibst, wird ja direkt von urpmi aufgelöst.

Ok, danke erst einmal für die Info/Hilfe.

Grüße,
Lutz

doktor5000 hat geschrieben:Richtig, und pkgconfig ist kein BuildRequire, der Provides-Tag, den du als Buildrequire angibst, wird ja direkt von urpmi aufgelöst.

Außerdem sollte man nach dem Bauvorgang das Binärpaket mal mit

Code: Alles auswählen

rpm -qpR Paketname

auf Duplikate in den Laufzeitabhängigkeiten untersuchen. Gelegentlich will man ganz sicher gehen und schreibt in "Requires" das rein, was das Upstream-Projekt als Abhängigkeiten angibt. Doch urpmi (bzw. eigentlich rpm) findet anhand von Systemaufrufen während des Bauvorgangs eine Menge Laufzeitabhängigkeiten selbst. In den Paketbau-Richtlinien gibt es dazu noch ein paar Infos mehr.

mbl103 hat geschrieben:Außerdem sollte man nach dem Bauvorgang das Binärpaket mal mit

Code: Alles auswählen

rpm -qpR Paketname

auf Duplikate in den Laufzeitabhängigkeiten untersuchen. Gelegentlich will man ganz sicher gehen und schreibt in "Requires" das rein, was das Upstream-Projekt als Abhängigkeiten angibt. Doch urpmi (bzw. eigentlich rpm) findet anhand von Systemaufrufen während des Bauvorgangs eine Menge Laufzeitabhängigkeiten selbst. In den Paketbau-Richtlinien gibt es dazu noch ein paar Infos mehr.

Einfacher ist es wahrscheinlich, sich die Fautregel zu merken:

Generell Requires nicht angeben, es sei denn man stellt bei einer Minimalinstallation fest, dass tatsächlich etwas
fehlt oder wenn explizit eine bestimmte Version einer Bibliothek gebraucht wird. Kommt aber recht selten vor.

doktor5000 hat geschrieben:...
fehlt oder wenn explizit eine bestimmte Version einer Bibliothek gebraucht wird. Kommt aber recht selten vor.

Von den hin und wieder erforderlichen expliziten Versionsangaben mal abgesehen, haben wir bei den Skriptsprachen (Python etc.) den umgekehrten Fall. Hier findet rpm in aller Regel überhaupt keine Laufzeitabhängigkeiten, nur den jeweiligen Skriptspracheninterpreter selbst. Da bleibt nur zu hoffen, dass die Entwickler in den Installationsanweisungen die benötigten Module angegeben haben, ansonsten hilft ein Blick in die Header der einzelnen Skripte.

Hmmm, das wäre mir neu.
Die benötigten Abhängigkeiten werden automatisch gefunden für: perl, python, ruby, ocaml, tcl, php, gobject-introspection und noch ein paar andere.
Redest du von Mageia oder im allgemeinen von Paketbau?

doktor5000 hat geschrieben:Redest du von Mageia oder im allgemeinen von Paketbau?

Nein, nicht speziell von Mageia, dafür habe ich noch keine Pakete gebaut. Aktuell habe ich Fedora, aber dieses Verhalten kenne ich auch noch von Mandriva.

Ein Beispiel für python-tornado:

Code: Alles auswählen

...
Group:          Development/Python
License:        ASL 2.0
URL:            http://www.tornadoweb.org
Source0:        http://github.com/downloads/facebook/tornado/%{oname}-%{version}.tar.gz
BuildArch:      noarch
BuildRequires:   python-devel
Requires:   python
Requires:       python-pycurl
Requires:       python-simplejson
...

Und die spec-Datei für das Fedora-Paket:

Code: Alles auswählen

...
Group:          Development/Libraries
License:        ASL 2.0
URL:            http://www.tornadoweb.org
Source0:        http://github.com/downloads/facebook/%{pkgname}/%{pkgname}-%{version}.tar.gz
BuildRoot:      %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildArch:      noarch

BuildRequires:  python-devel
Requires:       python-pycurl
Requires:       python-simplejson
...

Bei beiden Distributionen müssen Laufzeitabhängigkeiten explizit angegeben werden, weil rpm zwar Compiler-Aufrufe auswertet (bei Python-Paketen, die C-Erweiterungen enthalten und damit nicht noarch sind), aber nicht die Header von Python-Skripten. Durch die Angabe von "BuildRequires: python-devel" wird die Laufzeitabhängigkeit für Python erzeugt, aber das ist auch schon alles.
Übrigens ist wie schon oben erwähnt die Angabe von "Requires: python" im Mageia-Paket überflüssig, wie diese Ausgabe zeigt:

Code: Alles auswählen

$ rpm -qpR python-tornado-2.3-2.mga3.noarch.rpm
Warnung: python-tornado-2.3-2.mga3.noarch.rpm: Header V3 RSA/SHA1 Signature, Schlüssel-ID 80420f66: NOKEY
python
python-pycurl
python-simplejson
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
python(abi) = 2.7
rpmlib(PayloadIsXz) <= 5.2-1

"python" an sich ergibt sowieso kaum Sinn, denn rpm verweist hier mit "python(abi) = 2.7" ausdrücklich auf Python 2.