Build Service/Pakete für mehrere Distributionen

aus openSUSE, der freien Wissensdatenbank

Überblick

Diese Anleitung enthält spezielle Hinweise, wie Sie mit einer einzigen spec-Datei für verschiedene Distributionen arbeiten. Dies ist keine Einführung in den Paketbau für Anfänger, suchen Sie Informationen darüber, dann schauen Sie sich das SUSE Build Tutorial an. Auch der Bau von Debian-Paketen wird hier nicht behandelt.

Der Build Service kann nicht nur zuverlässige Paket-rpms für openSUSE bauen, sondern auch für aktuelle Fedora- und Mandriva-Distributionen.

Wo liegen die Grenzen? Die einzige praktische Begrenzung liegt darin, dass bestimmte Abhängigkeiten für Fedora oder Mandriva nicht so einfach aufgelöst werden können, während sie für openSUSE-Distributionen einfach durch eine Verknüpfung mit anderen Build Service-Projekten erfüllt werden können. Ein Beispiel: Für openSUSE ist es einfach, Pakete zu bauen, die die aktuellste Version von Qt4 oder GTK2 benötigen, da diese Abhängigkeiten von anderen Depots im Build Service bereitgestellt werden können, welche Rückportierungen neuer Qt4-Pakete auf ältere Versionen von openSUSE oder SLES/D anbieten. Diese Einschränkung kann für andere Distributionen nur umgangen werden, indem die notwendigen Abhängigkeiten im eigenen Projekt bereitgestellt werden. Gerade dann, wenn Sie so viele Distributionsversionen wie möglich unterstützen wollen.

Einige Stolpersteine auf die Sie acht geben sollten:

• Installieren von desktop-Dateien - Jede der drei Distributionen nutzt einen etwas anderen Mechanismus zur Installation von desktop-Dateien und zur Erstellung von Menüeinträgen. Mandriva nutzt dafür sogar ein spezielles RPM-Makro %update_menus um dies zu machen, welches eine Debian-ähnliche Einrichtung verwendet, anders als openSUSE oder Fedora. Beispiel:

%post
%update_menus

%postun
%clean_menus

• Paketnamensgebung für Abhängigkeiten. Schauen Sie weiter unten auf dieser Seite, dort finden Sie mehr spezifische Hinweise und Tricks, um die in ihren spec-Dateien zum Laufen zu kriegen.

• Die RPM-Makros weisen bei jeder Distribution feine Unterschiede auf. Am Ende dieses Artikels finden Sie eine Verknüpfung zu einer Tabelle, in welcher die verschiedenen Varianten verglichen werden.

Gibt es irgendwo ein gutes Beispiel für ein Paket für mehrere Distributionen?

Amilcars KDevelop-Paket (benötigt eine Build Service-Anmeldung)

Erkennen einer Distributionsvariante

Sie können

%if %{defined suse_version}
%if %{undefined suse_version}

oder portabler

%if 0%{?suse_version}
  <Hier das SUSE-Zeug>
%else
  <hier andere Distributionen>
%endif

hinzufügen, um zu prüfen, ob der aktuelle Bauvorgang für eine SUSE-Distribution stattfindet oder nicht. Sie können außerdem feststellen, für welche Distribution gebaut wird, indem Sie bspw.

%if 0%{?suse_version} > 930

verwenden, um etwas für alles nach SUSE Linux 9.3 auszuführen. Ähnliche Prüfungen existieren auch für andere Distributionen.

%if %{defined fedora_version}
%if %{defined mandriva_version}
%if 0%{?fedora_version} < 5
%if 0%{?mandriva_version} > 2006

Beachten Sie, dass rpm folgenden bevorzugt:

>= 

gegenüber

=>

Genauso können Sie eine bestimmte Version gezielt ausschließen:

%if 0%{?rhel_version} != 406

Sie können mehrer Distributionen ein einem einzelnen if-Block zusammenfassen, wie hier:

%if 0%{?fedora_version} || 0%{?rhel_version} || 0%{?centos_version}
 <ihr Zeug>
%endif

Sie können auch eine spezielle Architektur bestimmen, indem Sie bspw. folgendes verwenden:

%if 0%{?suse_version} == 1030
%ifarch x86_64
 <ihr Zeug>
%endif
%endif

Die folgende Übersicht hilft dabei, die korrekten Einstellungen zu wählen:

Installieren von Info-Dateien

Info-Dateien sollten mit den Makros %info_add und %info_del gehandhabt werden. Beispiel:

%post
%info_add %{name}.info

%pre
%info_del %{name}.info

Beachten Sie bitte, dass Info-Dateien auf manchen Distributionen als .gz und auf anderen als .bz2 komprimiert werden. Sie können das Makro %ext_info für die Dateiendung in der Dateiliste verwenden.

Abhängigkeiten handhaben

Verschiedene Distributionen verwenden oft verschiedene Namen für Pakete, so dass die Markierungen Requires: und BuildRequires: von Depot zu Depot angepasst werden müssen. Der zweite Vortrag auf dem FOSDEM erwähnt, dass "[Ein] Projekt für jedes Depot die Abhängigkeitsregeln umschreiben kann" (... Details benötigt ...)

Qt 3.x auf Fedora finden

Redhat/Fedora verwendet ein anderes Namensschema und eine andere Baueinrichtung um Qt zum Bau von anderen Anwendungen zu verwenden. Hier nun ein Weg, mit dem man Qt-basierte Anwendungen auf SUSE und Fedora mit einer spec-Datei bauen kann:

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_version} >= 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_version} >= 5
source "%{_sysconfdir}/profile.d/qt.sh"
%endif
%configure \
%if 0%{?fedora_version} >= 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

Qt4 auf Mandriva finden

Standardmäßig wird Qt3 vor Qt4 gefunden, weshalb Sie einfach das folgende dem %build-Abschnitt ihrer spec-Datei hinzufügen:

%build  
 
%if 0%{?mandriva_version} > 2006  
export PATH=/usr/lib/qt4/bin:$PATH  
export QTDIR=%{_prefix}/lib/qt4/  
%endif  

• Dies kann sich unter Mandriva 2008 geändert haben

Provides/Obsoletes unter Mandriva handhaben

Besondere Beachtung benötigen diese Fälle unter Mandriva, da hier oftmals - anders als bei Fedora oder openSUSE - separate Bibliotheks-rpms für viele Anwendungen erstellt werden, welche diese Bibliotheken jedoch alleine nutzen. Anwendung soundso kann also eine Abhängigkeit zu libsoundso oder libsoundso-0 aufweisen. Um Konflikte bei der Installation zu vermeiden, sollten Sie deshalb die originalen Mandriva-spec-Dateien daraufhin überprüfen, ob dort explizite Provides und Obsoletes angegeben sind. Auch wenn mit der Angabe Autoreqprov: on in der spec-Datei die Abhängigkeiten automatisch überprüft werden (was trotzdem eine gute Idee ist), kann es immer noch nötig sein, explizit die unten angegeben Zeilen hinzuzufügen:

%if 0%{?mandriva_version}
Provides: soundso liblibsoundso-0
Obsoletes: soundso liblibsolundso-0
%endif

Auf älteren Distributionen bauen

Während die Quellen in einem Paket auch unter älteren Distributionen gebaut werden können, kann sich der Weg, wie die Pakete gebaut werden, in der Zwischenzeit weiterentwickelt haben.

Wenn bspw. autoreconf -fi aufgerufen wird (was üblicherweise in spec-Dateien geschieht), kann es passieren (auf Grund des -i für installieren), dass die Versionen von config.sub, config.guess und ltmain.sh aus dem tar-Archiv mit den Versionen von autoconf auf der Zielplattform überschrieben werden. Das kann bedeuten, dass Dateien aus dem Jahr 2007 durch Versionen von 2005 ersetzt werden, wenn bspw. für SLE10 gebaut wird, was möglicherweise nicht vernünftig funktioniert. Die kann negative Auswirkungen haben und sogar zu einem Misskompilieren führen, wenn bpsw. libapt1 auf SLE10 gebaut wird.

Deshalb könnte es auf Zielplattformen die älter als Factory sind besser oder sogar erforderlich sein, dass Sie autoheader, autoconf oder was auch immer von Hand aufrufen, anstatt autoreconf zu verwenden. Das würde bspw. so aussehen:

%if 0%{?suse_version} > 1010
  autoreconf -fi
%else
  autoheader
  autoconf
%endif

Pakete für Debian und xUbuntu

Informationen zum Bau von Paketen für diese Distributionen finden Sie auf der Seite Build Service/Debs bauen.

Distro-RPM-Makros und Dokumentation

• SUSE-Paketbaukonventionen
• Fedora RPM-Leitfaden
• Fedora Paketbauleitlinien
• Mandriva-Paketbau
• Vergleich von RPM-Makros unter RHEL,Mandriva,Suse RPM Macros