* Manfred Tremmel wrote on Tue, Dec 20, 2005 at 21:18 +0100:
Am Dienstag 20 Dezember 2005 20:25 schrieb lothar.behrens@lollisoft.de:
SRPM in ersten Schritt. Damit der Benutzer die Wahl zwischen tgz und rpm hat. (Download bei sourceforge)
Welchen Sinn ein derartiges RPM haben sollte erschliest sich mir derzeit allerdings nicht ....
(mir auch nicht :))
der User hat die Sourcen installiert und in der RPM-Datanbank, das bringt ihm gar nichts.
Nee, ich glaub, Sourcen werden nichtmal in der DB vermerkt. Und so ein source-cp-RPM, welches aussieht wie binary aber sourcen ist, find ich eher Recht merkwürdig (selbst beim Kernel irgendwie komisch).
Ein Binary RPM möchte ich im zweiten Schritt machen. Hier sind Dinge zu beachten, wie Abhängigkeiten und das Einrichten einer Datenbank Quelle (ODBC) - %post.
Selbst ohne dieses hätte der User zumindest einmal ein installiertes Programm, dass er dann eben manuell konfigurieren muss.
Na, lieber vorsichtig mit Abhänigkeiten sein, finde ich. Libs macht RPM i.d.R. eh automatisch. Wenn man wirklich was ganz bestimmtes braucht, meinetwegen unixODBC, weil man direkt dagegen linkt, unportabel arbeitet etc, könnte man evtl. ein Require: einbauen, aber bloss nicht mit = und dreistelliger Versionsnummer :) Beim RPM installieren eine Datenbank einrichten, fände ich persönlich auch nicht gut. Wir hatten auch mal überlegt, diverse automatische installationsarbeiten (z.B. Datenbankstruktur-Update-Skripte) über postinstall oder so erledigen zu lassen, aber sofort erkannt, dass das falsch ist: installiert man beispielweise mehrere RPM Versionen parallel oder löscht eine installierte von fünf oder möchte die neue mal antesten aber die alte weiter betreiben, dann passt das alles nicht. Vielleicht will der Admin die Datenbank ja erst später umstellen usw.
Das würde erstmal reichen. Ich glaube langsam /usr/src/packages/SOURCE ist besser als irgendwo im HOME. Der Benutzer kann ja immer noch verschieben wie Er/Sie will.
FSH http://www.pathname.com/fhs/pub/fhs-2.3.html schreibt: | /usr/src : Source code (optional) | Purpose | | Source code may be place placed in this subdirectory, only for reference | purposes. [35] | | [35] | Generally, source should not be built within this hierarchy. also IMHO hier falsch (auch falsch, dass RPM hier baut; aber das ist ein anderes, sehr historisches Thema :))
Auf jeden Fall würde ich nichts in ein home-Verzeichnis packen, Du weißt ja eh nicht welcher User es verwendet und wie gesagt Du brauchst ein konkretes Verzeichnis, mit ~ ist da nix.
Ja, ~ geht gar nicht! Wir hatten damals auch ne längere Diskussion. Einmal hatten wir im rpm /tmp/<package> drin. Idee: der admin "muss" das RPM relokieren und damit "seinen" Pfad nehmen. Hat nicht gut funktioniert, weil sich dann doch schnell Packages in /tmp finden, weil der Admin das INSTALL nicht gelesen hat oder nach der Installation nix mehr ändern wollte - kann man ja verstehen. Dann hatten wir /usr/local/ überlegt - macht autoconf schliesslich per default. FHS sagt da leider nix dazu. Gibt /usr/local/bin und /usr/local/<package>/bin Konventionen. Ersteres findet sich meist im Pfad, mag ein wichtiger Vorteil sein, denke ich. Am Ende haben wir dann /opt/<provider>/<package> verwendet. Laut FHS müsste man zwar "LANANA registered" sein, aber weiss nichtmal, was das ist :) Hat den $PATH-Nachteil, der in unserem Fall kein Problem ist. Ausserdem gibt's "Binärprogram-Such-Skripte", die man sich nach $x/bin linken/kopieren kann. Für reine Beispielsourcen mag /usr/src ja gehen, aber ich würde dann lieber /usr/local/share oder so nehmen; hat man autoconf, kann man ja in /tmp/x bauen (configure/automake können das ja). Falls man denn jemanden findet, der /usr/, /usr/local/ oder /usr/local/share wirklich read-only hat UND so ein RPM installiert UND dort bauen möchte. ich z.B. hab immer gern in /usr/local/build/<package> oder /usr/local/build/<suse-version>/<package> gebaut, und die trees zwecks "make install" per NFS exportiert - funktioniert aber auch nur begrenzt :)
Ist mit meinem Makesystem nicht möglich. Für mich ist es Windows/Linux und Mac - Einheitlich, aber eben nicht automake und Konsorten. Das kommt vielleicht noch.
Trotzdem führst Du irgendwelche Schritte durch um das Programm zu bauen und zu installieren. Die sollten ins Spec-File.
Genau, dass kann "configure" sein, oder aber "meinScript", "true" oder gar nichts, install kann "make install" sein, oder ein paar "cp" oder ein paar "install -m" Zeilen. Technisch werden das ja eh nur Shellscripte, da kann man alles machen!
%files %defattr(-,root,root) /* .......
Und dann nichts in %files ?
Das war ein Witz. Bitte keine derartigen RPMs versuchen. Niemals installieren. Und vorallem: niemals deinstallieren :-)
Nochmal genau hinschauen, da steht "/*", das ist mehr wie nichts, genau genommen das Gegenteil von nichts -> alles.
(Müsste das nicht nur "/" heissen?) Beispiel wäre: %install make install DESTDIR=/usr/local/share/myPkg %files %defattr(-,root,root) /usr/local/share/myPkg aber nur, wenn man keine %doc und keine %confs hat, ist sonst bösartig rekursiv. Kann man nicht sagen, wenn man nix genaues weiss.
rüber), da schaut die Sache z.B. so aus (ich las die Patches mal weg):
(Ahh, danke für das prima Beispiel)
%{__make}
Standard RPM-Macro?
%install [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}
Auch Standard RPM? Der Test ist schon recht merkwürdig... Ist buildroot "/./", funktionierts ja eh nicht... Komisch, na ja.
%{__install} -d -m 0755 %{buildroot}%{_bindir} %{__install} -d -m 0755 %{buildroot}%{_sysconfdir} %{__install} -m 0755 lxdvdrip %{buildroot}/%{_bindir}/ %{__install} -m 0755 vamps/vamps_lxdvdrip %{buildroot}/%{_bindir}/ %{__install} -m 0755 vamps/play_cell_lxdvdrip %{buildroot}/%{_bindir}/ %{__install} -m 0644 doc-pak/lxdvdrip.conf.DE %{buildroot}%{_sysconfdir}/lxdvdrip.conf
Ahh, ja, prima, da kann er sich gleich die macros abschreiben, ja. Automake-zum-Selberbauen :)
Selbst Sourcen, die installiert werden (z.B. Kernel-Sourcen) sind ja in einem binary-RPM.
(Das ist IMHO ein Hack, aber egal :)) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.