openSUSE:Build Service für andere Distributionen/Gewusst-Wie
Inhaltsverzeichnis
- 1 Übersicht
- 2 Handhabung von Anweisungen, die von der Distribution abhängen
- 2.1 Installation von Info-Dateien
- 2.2 Handhabung von Abhängigkeiten
- 2.3 Suggests: gilt nur für SUSE 10.0
- 2.4 Qt 3.x auf Fedora/RHEL finden
- 2.5 Qt4 auf Mandriva finden
- 2.6 Behandeln von Mandriva Provides/Obsoletes
- 2.7 Auf alten Distributionen bauen
- 2.8 Debian und xUbuntu Pakete
- 2.9 Distro RPM Makros und Dokumentationen
Übersicht
Dieses "Gewußt Wie" liefert Hinweise darüber, wie man mit einer Spezifikationsdatei für verschiedene Distributionen arbeitet. Es ist keine Anfängeranleitung für Paketbauer. Bitte besuchen Sie statt dessen die Build Service Anleitung. Dieses Dokument deckt nicht die Distributionen ab, die Debian Pakete verwenden.
Der Build Service kann zuverlässige RPM-Pakete nicht nur für openSUSE bauen, sondern auch für die neuesten Distributionen wie SLES, CentOS, Fedora, Red Hat Enterprise Linux, Ubuntu, Debian und Mandriva.
Worin liegen die Grenzen? Die einzige praktische Grenze ist nicht, gewisse Abhängigkeiten zu haben, die Fedora oder Mandriva zufrieden stellen, wo sie leicht openSUSE Distributionen ausreichen, indem man sie zu anderen Build Service Projekten verlinkt oder verbindet (_link oder _aggregate). Ein Beispiel: Es ist einfach für SUSE-Distributionen Pakete zu bauen, die die neuesten Versionen von Qt4 oder GTK+ benötigen. Diese Abhängigkeiten können von anderen Repositorys des Build Srvice befriedigt werden, da diese Backports von neueren Qt4 Paketen für ältere SUSE-Versionen und SLES liefern. Das kann nur durch packen der benötigten Abhängigkeiten innerhalb Ihres eigenen Projektes überwunden werden. Auch dann ist dies nur ein Thema, wenn Sie wünschen, so viele Distributionen wie möglich zu unterstützen.
Einige Unterschiede zwischen den Distributionen auf die Sie achten sollten:
- Installation von Desktopdateien. Jede der fünf Distributionen verwenden einen etwas anderen Mechanismus zur Installation von Desktopdateien und erzeugen dann die menüeinträge. Mandriva hat ein spezielles RPM-Makro %update_menus, um das zu erreichen. Es verwendet eine Debian-ähnliche Einrichtung, anders als SUSE oder Fedora. Beispiel:
%post %update_menus %postun %clean_menus
- Paketbezeichnung für Abhängigkeiten. Lesen Sie unten mehr spezielle Hinweise und Tipps, damit es in Ihrer Spezifikationsdatei funktioniert.
- Unterschiede in RPM-Makros. Der Link mit einer Tafel zeigt unten die Variationen.
Kann man mich auf ein gutes Beispiel für ein Cross-Plattform-Paket verweisen?
Handhabung von Anweisungen, die von der Distribution abhängen
Um zu prüfen, ob der vorhandene Bau für eine SUSE Distribution ist oder nicht, können Sie dies hinzufügen:
%if %{defined suse_version}
%if %{undefined suse_version}
oder portabler:
%if 0%{?suse_version}
<suse stuff here>
%else
<other distros>
%endif
Beachten Sie, dass es kein '%elseif' gibt, um mehrfache Tests auf der gleichen Ebene auszuführen. Fedora verwendet "%{fedora}" ohne "_version".
Sie können prüfen, um welche SUSE Distribution es sich handelt, indem Sie
%if 0%{?suse_version} > 930
verwenden, zum Beispiel um etwas für alles nach SUSE Linux 9.3 auszuführen. Ähnliche Prüfungen gibt es auch für andere Distributionen.
%if %{defined fedora}
%if %{defined mdkversion}
%if 0%{?fedora} < 5
%if 0%{?mdkversion} > 2006
Beachten Sie, das RPM
>=
an Stelle von
=>
bevorzugt
Sie können eine spezielle Version ausschliessen:
%if 0%{?rhel_version} != 406
Sie können mehrere Distributionen in einem einzigen if-Block wie diesem kombinieren:
%if 0%{?fedora} || 0%{?rhel_version} || 0%{?centos_version}
<yourstuff>
%endif
Um Bedingungen zu gruppieren, teilen Sie die Bedingung auf verschiedene Zeile auf, wie hier:
# mono: only on suse, sle only from sle10
%if 0%{?suse_version}
%if 0%{?sles_version} == 0 || 0%{?sles_version} >= 1000
BuildRequires: mono-core
%endif
%endif
Gruppierungen mit runden Klammern werden auf fedora/rhel/centos Fehl schlagen:
# mono: nur auf SUSE, SLE nur ab SLE10
# SCHEITERT auf Fedora, RHEL ynd Centos:
%if 0%{?suse_version} && ( 0%{?sles_version} == 0 || 0%{?sles_version} >= 1000 )
BuildRequires: mono-core
%endif
Sie können auch eine spezielle Architektur auswählen:
%if 0%{?suse_version} == 1030
%ifarch x86_64
<yourstuff>
%endif
%endif
Die folgende Übersicht hilft, die passende Abfrage auszuwählen:
| Distribution | Variable | Kommentar |
|---|---|---|
| openSUSE Factory | %if 0%{?suse_version} > 1320 | kommende Version (wechselt) |
| openSUSE 13.2 | %if 0%{?suse_version} == 1320 | |
| openSUSE 13.1 | %if 0%{?suse_version} == 1310 | |
| openSUSE 12.3 | %if 0%{?suse_version} == 1230 | |
| openSUSE 12.2 | %if 0%{?suse_version} == 1220 | |
| openSUSE 12.1 | %if 0%{?suse_version} == 1210 | |
| openSUSE 11.4 | %if 0%{?suse_version} == 1140 | |
| openSUSE 11.3 | %if 0%{?suse_version} == 1130 | |
| openSUSE 11.1 | %if 0%{?suse_version} == 1110 | could also be SLE11 |
| openSUSE 11.0 | %if 0%{?suse_version} == 1100 | |
| openSUSE 10.3 | %if 0%{?suse_version} == 1030 | |
| openSUSE 10.2 | %if 0%{?suse_version} == 1020 | |
| SUSE Linux 10.1 | %if 0%{?suse_version} == 1010 | could also be SLE10 |
| SUSE Linux 10.0 | %if 0%{?suse_version} == 1000 | |
| SUSE Linux 9.3 | %if 0%{?suse_version} == 930 | |
| SLES 9 | %if 0%{?sles_version} == 9 | also set: %if 0%{?suse_version} == 910 |
| SLE 10 | %if 0%{?sles_version} == 10 | also set: %if 0%{?suse_version} == 1010 |
| SLE 11 | %if 0%{?sles_version} == 11 | also set: %if 0%{?suse_version} == 1110 |
| SLE 12 | %if 0%{?sles_version} == 1215 | also set: %if 0%{?suse_version} == 1215 |
| CentOS 5 | %if 0%{?centos_version} == 504 | |
| RHEL 4 | %if 0%{?rhel_version} == 406 | |
| RHEL 5 | %if 0%{?rhel_version} == 501 | |
| RHEL 6 | %if 0%{?rhel_version} == 600 | |
| Fedora 6 with Extras | %if 0%{?fedora} == 6 | |
| Fedora 7 with Extras | %if 0%{?fedora} == 7 | |
| Fedora 8 with Extras | %if 0%{?fedora} == 8 | |
| Fedora 9 with Extras | %if 0%{?fedora} == 9 | |
| Fedora 10 with Extras | %if 0%{?fedora} == 10 | |
| Fedora 11 with Extras | %if 0%{?fedora} == 11 | |
| Mandriva 2006 | %if 0%{?mdkversion} == 2006 | |
| Mandriva 2007 | %if 0%{?mdkversion} == 2007 | |
| Mandriva 2008 | %if 0%{?mdkversion} == 2008 | |
| Mandriva 2009.0 | %if 0%{?mdkversion} == 2009 | |
| Mandriva 2009.1 | %if 0%{?mdkversion} == 200910 | |
| Mandriva 2010.0 | %if 0%{?mdkversion} == 201000 |
ServicePacks können nicht gekennzeichnet werden. SLES11 SP1 setzt exakt die gleichen Variablen wie SLES11.
Installation von Info-Dateien
Info-Dateien sollten installiert werden, indem man die Makros %info_add und %info_del verwendet. Zum Beispiel
%post
%info_add %{name}.info
%preun
%info_del %{name}.info
Bitte beachten Sie, dass die Info-Dateien bei manchen Distributionen als .gz und als .bz2 oder eben .lzma (das neueste Mandriva) komprimiert werden. Sie können für den Datei-Suffix %ext_info in der Dateiliste verwenden.
Handhabung von Abhängigkeiten
Unterschiedliche Distributionen benutzen oft unterschiedliche Namen für Pakete, sodass die Markierungen Requires: und BuildRequires: von Repository zu Repository variieren. Es ist möglich, bei der Konfiguration eines Projektes alternative Paketbezeichnungen anzugeben. Zum Beispiel
%if 0%{?fedora}
Substitute: libnetcdf-devel netcdf
%endif
Um Ihre Projektkonfiguration zu ändern, verwenden Sie osc meta prjconf <project-name> -e, was $EDITOR startet. Das ist derzeit noch nicht mit einem Webclient möglich.
Suggests: gilt nur für SUSE 10.0
# 'Suggests:' ist eine SUSE Funktion. Machen Sie kein "Requires:" daraus,
# das Paket braucht kein vi oder graphviz, um zu laufen.
%if 0%{?suse_version} > 1000
# wahrscheinlich sind 920 oder 930 auch OK. Nicht für SLE9 910.
Suggests: vim graphviz
%endif
Qt 3.x auf Fedora/RHEL finden
Redhat/Fedora verwendet andere Schemen und Baueinrichtungen, um Qt zu verwenden und andere Anwendungen zu bauen. Hier ist ein Beispiel aus einer Spezifikationsdatei, um auf Qt basierte Anwendungen auf SUSE und Fedora in einer Spezifikationsdatei zu bauen:
BuildRequires: cups cups-devel python-devel shared-mime-info libart_lgpl-devel libtiff-devel libxml2-devel
BuildRequires: fontconfig-devel openssl-devel pkgconfig desktop-file-utils qt-devel
%if 0%{?fedora} >= 5
BuildRequires: libstdc++-devel gcc-c++ lcms-devel >= 1.12 qt
%endif
%if 0%{?suse_version} > 910
BuildRequires: update-desktop-files
%endif
Dann:
%if 0%{?fedora} >= 5
source "%{_sysconfdir}/profile.d/qt.sh"
%endif
%configure \
%if 0%{?fedora} >= 5
--with-xinerama \
--with-extra-libs=%{_libdir} \
%endif
%if 0%{?suse_version} > 910
--with-qt-libraries=/usr/%_lib/qt3/%_lib \
--with-docdir=%{prefix}/share/doc/packages/scribus \
%ifarch x86_64 ppc64 s390x
--enable-libsuffix=64 \
%endif
%endif
<programoptions>
Qt4 auf Mandriva finden
Per Standard wird Qt3 vor Qt4 gefunden. Fügen Sie einfach dies im Abschnitt %build in Ihrer Spezifikationsdatei ein:
%build
%if 0%{?mandriva_version} > 2006
export PATH=/usr/lib/qt4/bin:$PATH
export QTDIR=%{_prefix}/lib/qt4/
%endif
- Das könnte sich auf Mdv 2008 geändert haben.
Behandeln von Mandriva Provides/Obsoletes
Besondere Sorgfalt ist beim Umgang mit Mandriva nötig, da dort im Gegensatz zu CentOS, RHEL, Fedora oder SUSE für viele Programme, die private Kopien von Bibliotheken verwenden, eigene Bibliotheks-RPMs verwenden. Das Programm blafasel kann daher eine Abhängigkeit zu libblafasel oder libblafasel-0 haben. Daher müssen Sie prüfen, ob die originalen Mandriva Spec-Dateien explizite Provides oder Obsoletes haben, um Konflikte bei der Installation zu vermeiden. Obwohl RPM Abhängigkeiten automatisch handhabt, müssen Sie diese eventuell explizit wie folgt hinzufügen:
%if 0%{?mandriva_version}
Provides: foo libfoo-0
Obsoletes: foo libfoo-0
%endif
Auf alten Distributionen bauen
Während Quellen in einem Paket auf älteren Distributionen bauen, entwickelt sich die Art, wie Pakete gebaut werden auf inkompatible Weise.
Zum Beispiel, wenn man autoreconf -fi aufruft (wie es gewöhnlich in Spezifikationsdateien gemacht wird), kann es passieren (wegen -i für installiere), dass die Versionen der Tarballs von config.sub, config.guess und ltmain.sh durch eine Version aus dem Paket autoconf der Zielplattform ersetzt wurden. Das kann bedeuten, dass Dateien aus dem Jahr 2007 durch Versionen aus 2005 ersetzt wurden, als sie für SLE10 gebaut wurden. Das könnte natürlich nicht besonders gut funktionieren. Das kann negative Effekte haben und zu Fehlkompilierungen führen, z.B. wenn man libapr1 auf SLE10 baut.
So könnte es besser oder auch erforderlich sein, dass Sie, autoheader, autoconf oder was immer benötigt wird, per Hand aufrufen, statt autoreconf auf Versionen, die älter als Factory sind. Ein Beispiel könnte sein:
%if 0%{?suse_version} > 1010
autoreconf -fi
%else
autoheader
autoconf
%endif
Debian und xUbuntu Pakete
Für diese Art Pakete lesen Sie bitte die Seiten unter Build Service/Debs bauen.