Hallo,
dies ist mein erster Versuch, ein SRPM zu erstellen. Es nutzt nicht die üblichen
./configure & make & make install Methoden, sollte aber auch anders gehen.
Also das tgz Archiv soll einfach in ~/develop/Projects entpackt werden.
Das enthaltene INSTALL Script enthält keine Befehle, nachdem ich es mit
rpmbuild -ba lbDMF.spec erstellt habe.
Was mache ich noch falsch ?
Danke, Lothar
Hier ist mein Spec File:
Summary: DMF - Distributed Multiplatform Framework
Name: lbdmf
Version: 0.6.0
Release: 1
Copyright: LGPL
Group: Development/Tools
Source: dist/lbDMF-Source-0.6.0.tgz
URL: http://www.lollisoft.de
Distribution: lbDMF Development System
Vendor: Lothar Behrens
Packager: Lothar Behrens
* lothar.behrens@lollisoft.de wrote on Mon, Dec 19, 2005 at 13:34 +0100: [...]
Was mache ich noch falsch ?
Fehlt da nicht mindestens ein "%files"? Was sagt rpm -qilp
Am 19 Dec 2005 um 21:52 hat Steffen Dettmer geschrieben:
* lothar.behrens@lollisoft.de wrote on Mon, Dec 19, 2005 at 13:34 +0100: [...]
Was mache ich noch falsch ?
Fehlt da nicht mindestens ein "%files"? Was sagt rpm -qilp
, leer?
Es enthält meine tgz Datei und die spec Datei + die Metainformationen wie Summary. So wie ich das bis jetzt verstanden habe und es wohl in der Doku zu verstehen ist, sind die %files Angaben nur dazu da, ob tatsächlich Dateien installiert wurden. Diese können dann mit Hilfe der %files Angaben wieder 'deinstalliert' werden. Die Beispiele, die ich gesehen habe, wenden in %install 'make install' an. D.h. rpm weiß da wirklich nicht immer, was installiert wird. Also wenn ich in meinem makefile ein 'install' target einbaue, welches meinen Quellbaum (CPP im tgz File) kopiert, könnte es gehen. Weiter wird nur installiert, wenn in %files Einträge vorhanden sind. Oder ? D.h. es wird nur dann der %install Zweig ausgeführt ? Mein Test mit %files ~/develop/Projects geht nicht, denn rpm meckert rum mit Pfaden, die nicht mit / beginnen :-( Bin ich gezwungen, mit rpm meine Quellen in das /usr/src/<package> Verzeichnis zu legen. Oder viel mehr, sollte ich das so tun (Linux Filesystem Standard) ? Ich hoffe, das ist jetzt nicht zu viel :-) Gibt es eine bessere, oder kürzere Doku für Einsteiger als http://www.rpm.org/max-rpm ? Danke, Lothar
oki,
Steffen
-- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
-- Lothar Behrens | Rapid Prototyping ... Rosmarinstr 3 | 40235 Düsseldorf | www.lollisoft.de
Am Dienstag 20 Dezember 2005 11:57 schrieb lothar.behrens@lollisoft.de:
So wie ich das bis jetzt verstanden habe und es wohl in der Doku zu verstehen ist, sind die %files Angaben nur dazu da, ob tatsächlich Dateien installiert wurden. Diese können dann mit Hilfe der %files Angaben wieder 'deinstalliert' werden.
Nö, die %files Angaben enthalten die Verzeichnisse/Dateien, die in dem RPM landen sollen.
Die Beispiele, die ich gesehen habe, wenden in %install 'make install' an. D.h. rpm weiß da wirklich nicht immer, was installiert wird. Also wenn ich in meinem makefile ein 'install' target einbaue, welches meinen Quellbaum (CPP im tgz File) kopiert, könnte es gehen.
Dashalb sollte man "make install" nie so verwenden, denn beim RPM-Bau sollte nie ins reale System installiert werden, sondern in ein temporäres Verzeichnis. Am besten mit den vorgegebenen Makros arbeiten: %makeinstall
Weiter wird nur installiert, wenn in %files Einträge vorhanden sind. Oder ? D.h. es wird nur dann der %install Zweig ausgeführt ?
Soweit ich weiß wird %install unabhängig davon ausgeführt.
Mein Test mit
%files ~/develop/Projects
geht nicht, denn rpm meckert rum mit Pfaden, die nicht mit / beginnen :-(
Was willst Du denn überhaupt mit dem Home-Verzeichnis? Im %files Bereich werden die Verzeichnisse/Dateien absolut angegeben, wenn Du was im Home-Verzeichnis haben willst, nimm /home/lothar/develop/Projects (falls lothar Dein Username ist).
Bin ich gezwungen, mit rpm meine Quellen in das /usr/src/<package> Verzeichnis zu legen. Oder viel mehr, sollte ich das so tun (Linux Filesystem Standard) ?
Du solltest Die Sourcen immer in einen Tarball packen, den nach /usr/src/packages/SOURCES legen und den als Basis nehmen, niemals ein bereits existierendes Entwicklerverhzeichnis, das ist nicht reproduzierbar.
Ich hoffe, das ist jetzt nicht zu viel :-)
Gibt es eine bessere, oder kürzere Doku für Einsteiger als http://www.rpm.org/max-rpm ?
Hab nie ne Doku gelesen, schau Dir doch einfach mal ein paar SPEC-Files aus SOURCE-RPMs einfacher Pakete an. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am 20 Dec 2005 um 15:46 hat Manfred Tremmel geschrieben:
Am Dienstag 20 Dezember 2005 11:57 schrieb lothar.behrens@lollisoft.de:
So wie ich das bis jetzt verstanden habe und es wohl in der Doku zu verstehen ist, sind die %files Angaben nur dazu da, ob tatsächlich Dateien installiert wurden. Diese können dann mit Hilfe der %files Angaben wieder 'deinstalliert' werden.
Nö, die %files Angaben enthalten die Verzeichnisse/Dateien, die in dem RPM landen sollen.
Hmm, mein tgz File eben. Das soll durch die Angaben des Users irgendwo entpackt werden. Rpmbuild frisst es auch und stellt dessen Verzeichnis in /usr/src/packages/BUILD rein. (rpmbuild -ba <specfile>)
Die Beispiele, die ich gesehen habe, wenden in %install 'make install' an. D.h. rpm weiß da wirklich nicht immer, was installiert wird. Also wenn ich in meinem makefile ein 'install' target einbaue, welches meinen Quellbaum (CPP im tgz File) kopiert, könnte es gehen.
Dashalb sollte man "make install" nie so verwenden, denn beim RPM-Bau sollte nie ins reale System installiert werden, sondern in ein temporäres Verzeichnis. Am besten mit den vorgegebenen Makros arbeiten: %makeinstall
Das mit make install oder %makeinstall lasse ich besser noch.
Weiter wird nur installiert, wenn in %files Einträge vorhanden sind. Oder ? D.h. es wird nur dann der %install Zweig ausgeführt ?
Soweit ich weiß wird %install unabhängig davon ausgeführt.
Mein Test mit
%files ~/develop/Projects
geht nicht, denn rpm meckert rum mit Pfaden, die nicht mit / beginnen :-(
Was willst Du denn überhaupt mit dem Home-Verzeichnis? Im %files Bereich werden die Verzeichnisse/Dateien absolut angegeben, wenn Du was im Home-Verzeichnis haben willst, nimm /home/lothar/develop/Projects (falls lothar Dein Username ist).
Ich bin nicht gezwungen, die Quellen (CPP Verzeichnis im tgz), dort abzulegen. Es muss dann nur eine Umgebungsvariable angepasst werden. Ich verwende nun mal mein Home Verzeichnis um darin an den Quellen zu arbeiten.
Bin ich gezwungen, mit rpm meine Quellen in das /usr/src/<package> Verzeichnis zu legen. Oder viel mehr, sollte ich das so tun (Linux Filesystem Standard) ?
Du solltest Die Sourcen immer in einen Tarball packen, den nach /usr/src/packages/SOURCES legen und den als Basis nehmen, niemals
So habe ich das auch gemacht, nachdem rpmbuild den tarball nicht gefunden hat.
ein bereits existierendes Entwicklerverhzeichnis, das ist nicht reproduzierbar.
Ich mache ein CVS export, um das dann in ein tarball zu packen. Dies wird dann in /usr/src/packages/SOURCES kopiert. Das nimmt rpmbuild auch und es ist dannach im rpm File. Nur die Installation geht nicht - es passiert nichts.
Ich hoffe, das ist jetzt nicht zu viel :-)
Gibt es eine bessere, oder kürzere Doku für Einsteiger als http://www.rpm.org/max-rpm ?
Hab nie ne Doku gelesen, schau Dir doch einfach mal ein paar SPEC-Files aus SOURCE-RPMs einfacher Pakete an.
Habe ein Tool gefunden (rust.sourceforge.net), das rpm Dateien erstellen können soll. Dies enthält ein spec File, das einfach ist. Werde das mal als Grundlage verwenden. Ich verstehe nur nicht, warum ich im %files Zweig die Dateien nochmal angeben muss. Die sind ja im tgz File und das findet rpmbuild ja schon. Danke, Lothar
-- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
-- Lothar Behrens | Rapid Prototyping ... Rosmarinstr 3 | 40235 Düsseldorf | www.lollisoft.de
* lothar.behrens@lollisoft.de (lothar.behrens@lollisoft.de) [20051220 17:21]:
mein tgz File eben. Das soll durch die Angaben des Users irgendwo entpackt werden.
Welches tgz File? Normalerweise besteht ja der Inhalt eines .src.rpm aus einem Tarball, einer .spec Datei und evtl. noch einem oder mehreren Patches.
Das mit make install oder %makeinstall lasse ich besser noch.
Warum? Ist im Prinzip ganz einfach. Bau einfach eine Variable in die Makefiles ein, die normalerweise leer ist. Wenn du automake zum Erstellen der Makefiles benutzt, wird dafür DESTDIR verwendet. Das sieht dann gekürzt so aus: prefix = /usr/local bindir =$(prefix)/bin DESTDIR = install: install -d $(DESTDIR)/$(bindir) install $(PROGRAMS) $(DESTDIR)/$(bindir) Innerhalb der .spec Datei rufst du nun make so auf: make DESTDIR=%{buildroot} Und wenn Buildroot verwendet wird (das sollte immer der Fall sein), wird die Software nun dorthin kopiert und RPM packt sie dann in das .rpm mit den in der %files Sektion angegebenen Pfaden.
Ich mache ein CVS export, um das dann in ein tarball zu packen. Dies wird dann in /usr/src/packages/SOURCES kopiert. Das nimmt rpmbuild auch und es ist dannach im rpm File. Nur die Installation geht nicht - es passiert nichts.
Nimm dir ein beliebiges GNU Paket und schau dir mal an, wie bei 'make dist' der Tarball produziert wird. *So* sollte auch deiner aussehen, sprich ein nicht absolutes Verzeichnis beinhalten, unterhalb dessen der Quellcode-Baum liegt.
Ich verstehe nur nicht, warum ich im %files Zweig die Dateien nochmal angeben muss. Die sind ja im tgz File und das findet rpmbuild ja schon.
Das sind doch zwei Paar Schuhe! In deinem Tarball liegen die *Quellen*. In der %files Sektion gibst du an, welche der Dateien in das zu bauende binäre .rpm gepackt werden sollen. Du willst ja normalerweise nicht, dass dieses auch den Quellcode beinhaltet. [Signatures zitiert man nicht!] Philipp -- Philipp Thomas <pth BEI suse.de> R&D SUSE LINUX Products GmbH, Maxherrnstr. 23, D-90409 Nürnberg
Am 20 Dec 2005 um 18:03 hat Philipp Thomas geschrieben:
* lothar.behrens@lollisoft.de (lothar.behrens@lollisoft.de) [20051220 17:21]:
mein tgz File eben. Das soll durch die Angaben des Users irgendwo entpackt werden.
Welches tgz File? Normalerweise besteht ja der Inhalt eines .src.rpm aus einem Tarball, einer .spec Datei und evtl. noch einem oder mehreren Patches.
Das, das ich aus meinem CVS export vor dem RPM Bau erzeuge. Lt. der Doku in
meinem letzten Posting wird das ja wieder in den BUILD Zweig entpackt. (%prep)
Also hier nochmal kurz mein Specfile:
Summary: DMF - Distributed Multiplatform Framework
Name: lbdmf
Version: 0.6.0
Release: 1
Copyright: LGPL
Group: Development/Tools
Source: lbDMF-Source-0.6.0.tgz
URL: http://www.lollisoft.de
Distribution: lbDMF Development System
Vendor: Lothar Behrens
Packager: Lothar Behrens
Das mit make install oder %makeinstall lasse ich besser noch.
Warum? Ist im Prinzip ganz einfach. Bau einfach eine Variable in die Makefiles ein, die normalerweise leer ist. Wenn du automake zum Erstellen der Makefiles benutzt, wird dafür DESTDIR verwendet. Das sieht dann gekürzt so aus:
prefix = /usr/local bindir =$(prefix)/bin
DESTDIR =
install: install -d $(DESTDIR)/$(bindir) install $(PROGRAMS) $(DESTDIR)/$(bindir)
Innerhalb der .spec Datei rufst du nun make so auf:
make DESTDIR=%{buildroot}
Das ist mir dann klar, auch wenn ich kein Automake verwende. Ich verwende mein eigenes Makesystem, welches auch unter Windoof und Mac OS X geht. Also dann zeigt mein DESTDIR nach ~, wobei binaries in ein $DESTDIR/bin, shared libraries in $DESTDIR/lib und Plugins in $DESTDIR/plugins gepackt werden. (Nach dem Linken) Ok, $(DESTDIR)/$(bindir) hat evtl. einen doppelten /, aber sollte nicht stören. %build und %install dann so: %build # Wie oben %install make install # Ohne verbiegen des DESTDIR
Und wenn Buildroot verwendet wird (das sollte immer der Fall sein), wird die Software nun dorthin kopiert und RPM packt sie dann in das .rpm mit den in der %files Sektion angegebenen Pfaden.
Wo ist Buildroot im obigen Beispiel definiert ?
Ich mache ein CVS export, um das dann in ein tarball zu packen. Dies wird dann in /usr/src/packages/SOURCES kopiert. Das nimmt rpmbuild auch und es ist dannach im rpm File. Nur die Installation geht nicht - es passiert nichts.
Nimm dir ein beliebiges GNU Paket und schau dir mal an, wie bei 'make dist' der Tarball produziert wird. *So* sollte auch deiner aussehen, sprich ein nicht absolutes Verzeichnis beinhalten, unterhalb dessen der Quellcode-Baum liegt.
Das ist mein Script zur Tarball Erstellung: #!/bin/sh # Steht selbst in CPP if [ -e "dist" ]; then rm -R dist; fi mkdir dist cd dist cvs -d:ext:lollisoft@cvs.sourceforge.net:/cvsroot/lbdmf export -r HEAD CPP # Nicht im CVS enthalten: cp ../Plugins/DatabaseReport/repwrt.cpp CPP/Plugins/DatabaseReport/repwrt.cpp cp ../Plugins/DatabaseReport/repwrt.h CPP/Plugins/DatabaseReport/repwrt.h tar cvzf lbDMF-Source-$1.tgz CPP/ cp lbDMF-Source-$1.tgz /usr/src/packages/SOURCES cd .. rpmbuild -ba lbDMF.spec
Ich verstehe nur nicht, warum ich im %files Zweig die Dateien nochmal angeben muss. Die sind ja im tgz File und das findet rpmbuild ja schon.
Das sind doch zwei Paar Schuhe! In deinem Tarball liegen die *Quellen*. In der %files Sektion gibst du an, welche der Dateien in das zu bauende binäre .rpm gepackt werden sollen. Du willst ja normalerweise nicht, dass dieses auch den Quellcode beinhaltet.
Ach sooooo :-) Wenn mein Tarball nun folgenden Inhalt hätte: CPP/BaseDevelopment/lbHook/lbHook.cpp und nach dem Bauen dort (entpackt) ein lbHook.so ist, dann muss ich %files $RPM_BUILD_DIR/CPP/BaseDevelopment/lbHook/lbHook.so stehen haben ? Denn rpm entpackt ja in $RPM_BUILD_DIR (Siehe %prep) und wärend des Compiliervorgangs ist mein DEVROOT oder DESTDIR = %{buildroot} und %{buildroot} ist lt. meinem Verständniss nun $RPM_BUILD_DIR. Richtig ? Nun fehlt mir nur noch die Verbindung, zum Ziel Installationsort einer bestimmten Datei, die im Binary RPM steht. Wird dafür dann %prefix/bin genommen, ist mir alles klar. Ich hoffe jetzt so viel verstanden zu haben, dass es klappt :-)
[Signatures zitiert man nicht!]
Sorry Danke, Lothar -- Lothar Behrens | Rapid Prototyping ... Rosmarinstr 3 | 40235 Düsseldorf | www.lollisoft.de
On Tue, 20 Dec 2005 19:38:47 +0100, lothar.behrens@lollisoft.de wrote:
Also dann zeigt mein DESTDIR nach ~, wobei binaries in ein $DESTDIR/bin, shared libraries in $DESTDIR/lib und Plugins in $DESTDIR/plugins gepackt werden. (Nach dem Linken)
Du scheinst es immer noch nicht zu verstehen! 1. *Vor dem Bauen der RPM-Pakete* erzeugst du einen CVS-Abzug und daraus einen Tarball, in diesem Fall also lbDMF-Source-0.6.0.tgz, dessen Verzeichnisbaum mit lbDMF-0.6.0 beginnt: lbDMF-0.6.0 --- src --- doc --- include etc. ... Im Kopf der .spec Datei steht deshalb (gekürzt) in etwa: -------------schnipp------------------- Name: lbDMF Version: 0.6.0 Source: %{name}-SOURCE-%{version}.tgz Buildroot: /var/tmp/%{name}-%{version}-root %prep %setup -q %build # hier werden jetzt die Binaries (Programme, Tools, Bibliotheken # etc gebaut. %install # Hier installierst du dann die gebauten binaries plus Header # usw. in die entsprechenden Verzeichnisse ( also z.B. /usr/bin, # /usr/lib bzw. /usr/lib64, /usr/include etc), was ja normaler- # weise im Makefile passiert. # Dein Build-system sollte jetzt die Verwendung von Variablen er # möglichen, damit du jetzt DESTDIR=%{buildroot} übergeben kannst, # sprich tatsächlich nach %{buildroot}/usr/bin etc. installiert # wird. NIEMALS sollte in das Home-Verzeichnis des Benutzers installiert werden, der rpmbuild aufruft. Philipp
Hallo Lothar, hallo Leute, Am Dienstag, 20. Dezember 2005 19:38 schrieb lothar.behrens@lollisoft.de: Wie wärs mit Realname im Absender? Würde sich nicht so holprig lesen wie die Mailadresse ;-) [...]
Also hier nochmal kurz mein Specfile:
%prep rm -rf $RPM_BUILD_DIR/lbDMF-Source-0.6.0 zcat $RPM_SOURCE_DIR/lbDMF-Source-0.6.0.tgz | tar -xvf -
%install rm -Rf ~/develop [...]
Warum verwendest Du hier nicht $RPM_BUILD_DIR? Ach ja: Das Bauen von RPMs sollte nicht irgendwo im Homeverzeichnis rumbasteln. Stell Dir vor, jemand will Dein RPM neu (aus dem SRPM) bauen: rpmbuild --rebuild foo.src.rpm Dummerweise hat er in ~/develop wichtige Daten, von denen natürlich[tm] kein Backup existiert. Hat? Hatte... Glaubst Du, dass der Dein Programm hinterher noch mag? ;-) Nochmal: arbeite unterhalb von $RPM_BUILD_DIR
#%files #~/develop/Projects
In auskommentierter Form dürfte Dein RPM ziemlich leer werden ;-) BTW: Im %files musst/darfst Du $RPM_BUILD_DIR *nicht* angeben - also einfach /irgendwo (nicht: $RPM_BUILD_DIR/irgendwo).
%install make install # Ohne verbiegen des DESTDIR
Wieso? Damit installierst Du direkt ins System und RPM sucht sich einen Wolf, weil $RPM_BUILD_DIR leer bleibt...
Das ist mein Script zur Tarball Erstellung:
#!/bin/sh # Steht selbst in CPP
if [ -e "dist" ]; then rm -R dist; fi
mkdir dist cd dist cvs -d:ext:lollisoft@cvs.sourceforge.net:/cvsroot/lbdmf export -r HEAD CPP # Nicht im CVS enthalten: cp ../Plugins/DatabaseReport/repwrt.cpp CPP/Plugins/DatabaseReport/repwrt.cpp cp ../Plugins/DatabaseReport/repwrt.h CPP/Plugins/DatabaseReport/repwrt.h tar cvzf lbDMF-Source-$1.tgz CPP/
Das heißt, Dein Tarball entpackt sich in ein Verzeichnis namens CPP. Besser (und üblich) wäre IMHO ein Verzeichnisname a la lbDMF-CPP-$version.
Wenn mein Tarball nun folgenden Inhalt hätte:
CPP/BaseDevelopment/lbHook/lbHook.cpp
und nach dem Bauen dort (entpackt) ein lbHook.so ist, dann muss ich
%files $RPM_BUILD_DIR/CPP/BaseDevelopment/lbHook/lbHook.so
stehen haben ?
Nö, nur /CPP/... - allerdings wirst Du (hoffentlich) nicht nach /CPP installieren, sondern z. B. /opt/lbDMF/ oder /usr oder ...
Denn rpm entpackt ja in $RPM_BUILD_DIR (Siehe %prep) und wärend des Compiliervorgangs ist mein DEVROOT oder DESTDIR = %{buildroot} und %{buildroot} ist lt. meinem Verständniss nun $RPM_BUILD_DIR.
Richtig ?
Nun fehlt mir nur noch die Verbindung, zum Ziel Installationsort einer bestimmten Datei, die im Binary RPM steht.
Wird dafür dann %prefix/bin genommen, ist mir alles klar.
Wie gesagt - innerhalb des $RPM_BUILD_DIR die gewünschte Verzeichnisstruktur anlegen und diese dann in %files angeben. Die Angabe in %files entspricht [1] dem Ziel-Installationsort. Gruß Christian Boltz [1] von Spezialitäten wie rpm -i --relocate beim Installieren des RPMs mal abgesehen - Du solltest aber erst mal die Grundlagen richtig verstehen, bevor Du an sowas denkst ;-) --
Kann man Outook-User nicht von Flatrates ausschliesen? ;-) Nein. Aber vielleicht kann man sie zur ausschliesslichen Benutzung von MSN.com zwingen und selbiges vom Rest des Internets abtrennen ... [> Manfred Tremmel und Wolfgang Weisselberg in linux-liste]
* Christian Boltz wrote on Thu, Dec 22, 2005 at 00:28 +0100: [...]
#%files
BTW, macros werden auch nach "#" expandiert! Am besten schreibt man #files statt %files also ohne %, sonst wird's expandiert. just BTW, weil gemeine Falle.
BTW: Im %files musst/darfst Du $RPM_BUILD_DIR *nicht* angeben - also einfach /irgendwo (nicht: $RPM_BUILD_DIR/irgendwo).
%install make install # Ohne verbiegen des DESTDIR
Wieso? Damit installierst Du direkt ins System und RPM sucht sich einen Wolf, weil $RPM_BUILD_DIR leer bleibt...
Na, aber $RPM_BUILD_DIR ist doch hier falsch, oder? Gab's für installroot nicht was eigenes? [...]
mkdir dist cd dist cvs -d:ext:lollisoft@cvs.sourceforge.net:/cvsroot/lbdmf export -r HEAD CPP
(lieber Tag, dann haben die Sourcen auch einen $Name: $ :))
tar cvzf lbDMF-Source-$1.tgz CPP/
Das heißt, Dein Tarball entpackt sich in ein Verzeichnis namens CPP. Besser (und üblich) wäre IMHO ein Verzeichnisname a la lbDMF-CPP-$version.
Ja, automake "make dist" würde das etwa so machen.
und nach dem Bauen dort (entpackt) ein lbHook.so ist, dann muss ich
%files $RPM_BUILD_DIR/CPP/BaseDevelopment/lbHook/lbHook.so
stehen haben ?
Ja, wenn Du nicht installierst, wäre das ein Weg. Das RPM möchte dann aber auch nach CPP/BaseDevelopment/lbHook/lbHook.so installieren!
Nö, nur /CPP/... - allerdings wirst Du (hoffentlich) nicht nach /CPP installieren, sondern z. B. /opt/lbDMF/ oder /usr oder ...
/CPP/ wäre ja rekursiv und hätte damit vermutlich die ganzen Sourcen nochmal drin.
Kann man Outook-User nicht von Flatrates ausschliesen? ;-) Nein. Aber vielleicht kann man sie zur ausschliesslichen Benutzung von MSN.com zwingen und selbiges vom Rest des Internets abtrennen ... [> Manfred Tremmel und Wolfgang Weisselberg in linux-liste]
(man bräuchte ein kryptisches nur-Text-Kommunikationsmedium (thttp oder tmail wobei t trivial heisst. Da dürften per Patent oder so nur Text-Modus-Clients mit commando-Befehlstruktur geschrieben werden. Ich glaub, das würde helfen :-)) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Am Dienstag 20 Dezember 2005 17:21 schrieb lothar.behrens@lollisoft.de:
Ich bin nicht gezwungen, die Quellen (CPP Verzeichnis im tgz), dort abzulegen. Es muss dann nur eine Umgebungsvariable angepasst werden. Ich verwende nun mal mein Home Verzeichnis um darin an den Quellen zu arbeiten.
Ja, aber was genau willst Du denn jetzt machen. Du hast im tarball (tgz) die Quellen, willst Du die jetzt in das RPM packen, oder das fertig compilierte Programm? Wenn Du nur die Sourcen drinnen haben willst (ähnlich dem kernel-default-source RPM bei SUSE, 1:1 wie sie im tarball liegen, reicht ein simples: ....... %prep %setup %build %install [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} %{__mkdir_p} %{buildroot}/verzeichnis/wo/es/hin/soll mv * %{buildroot}/verzeichnis/wo/es/hin/soll/ %clean [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} %files %defattr(-, root, root) /verzeichnis/wo/es/hin/soll/* ....... ausreichen (einfachste Variante). Wenn es um ne Installation geht, die alternativ auch per ./configure, make und make install durchführbar ist, dann tut es in der Regel ein: ....... %prep %setup %build %configure --prefix=%{buildroot} %__make %install [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} %{makeinstall} %clean [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} %files %defattr(-,root,root) /* .......
Ich mache ein CVS export, um das dann in ein tarball zu packen.
Ok.
Dies wird dann in /usr/src/packages/SOURCES kopiert. Das nimmt
Ok.
rpmbuild auch und es ist dannach im rpm File. Nur die Installation geht nicht - es passiert nichts.
Was sagt denn ein 'rpm -qlp <rpmname>'? Das sollte Dir alle Dateien anzeigen, die im RPM liegen. Per 'rpm -Uvh <rpmname>' werden die dann mit Sicherheit auch installiert. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am 20 Dec 2005 um 19:14 hat Manfred Tremmel geschrieben:
Am Dienstag 20 Dezember 2005 17:21 schrieb lothar.behrens@lollisoft.de:
Ich bin nicht gezwungen, die Quellen (CPP Verzeichnis im tgz), dort abzulegen. Es muss dann nur eine Umgebungsvariable angepasst werden. Ich verwende nun mal mein Home Verzeichnis um darin an den Quellen zu arbeiten.
Ja, aber was genau willst Du denn jetzt machen. Du hast im tarball (tgz) die Quellen, willst Du die jetzt in das RPM packen, oder das fertig compilierte Programm?
SRPM in ersten Schritt. Damit der Benutzer die Wahl zwischen tgz und rpm hat. (Download bei sourceforge) 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.
Wenn Du nur die Sourcen drinnen haben willst (ähnlich dem kernel-default-source RPM bei SUSE, 1:1 wie sie im tarball liegen, reicht ein simples:
....... %prep
%setup
%build
%install [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} %{__mkdir_p} %{buildroot}/verzeichnis/wo/es/hin/soll mv * %{buildroot}/verzeichnis/wo/es/hin/soll/
%clean [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}
%files %defattr(-, root, root) /verzeichnis/wo/es/hin/soll/* .......
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.
ausreichen (einfachste Variante). Wenn es um ne Installation geht, die alternativ auch per ./configure, make und make install durchführbar ist, dann tut es in der Regel ein:
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.
....... %prep
%setup
%build %configure --prefix=%{buildroot} %__make
%install [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} %{makeinstall}
%clean [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}
%files %defattr(-,root,root) /* .......
Und dann nichts in %files ? Das mit dem configure script könnte ich erst mal mit einem dummy realisieren. (Mit einer Warnung)
Ich mache ein CVS export, um das dann in ein tarball zu packen.
Ok.
Dies wird dann in /usr/src/packages/SOURCES kopiert. Das nimmt
Ok.
rpmbuild auch und es ist dannach im rpm File. Nur die Installation geht nicht - es passiert nichts.
Was sagt denn ein 'rpm -qlp <rpmname>'? Das sollte Dir alle Dateien anzeigen, die im RPM liegen. Per 'rpm -Uvh <rpmname>' werden die dann mit Sicherheit auch installiert.
rpm -i hat ja nichts gemacht. rpm -qlp zeigte die Dateien an und rpm -Uvh hat die tgz Datei wieder an Ihren Platz in /usr/src/packages/SOURCES gelegt. Das ist erst Mal gut so. Was fehlte, war ein korrekter rpm Befehl :-) Wenn ich denn mal alles richtig gemacht habe, ist dann ein rpm -i nur für RPM's und nicht für SRPM's gedacht ? Denn mit SRPM's habe ich nicht mal als Benutzer zu tun gehabt. Immer nur Yast :-( Das kommt denn davon, wenn man immer nur KlickiBunti GUI SW benutzt :-) Lothar -- Lothar Behrens | Rapid Prototyping ... Rosmarinstr 3 | 40235 Düsseldorf | www.lollisoft.de
Am 20. Dez 2005 20:25:59 +0100 schrieb lothar.behrens@lollisoft.de:
SRPM in ersten Schritt. Damit der Benutzer die Wahl zwischen tgz und rpm hat. (Download bei sourceforge)
Das .src.rpm wird, sofern rpmbuild nicht -bb übergeben wird, beim Bauen des Binär-RPMs automatisch mitgebaut. Philipp PS: Wir sollten die Diskussion nach suse-programming verlegen, denn u.a. für genau solche Fragen ist die Liste da.
* Philipp Thomas wrote on Tue, Dec 20, 2005 at 20:44 +0100:
Am 20. Dez 2005 20:25:59 +0100 schrieb lothar.behrens@lollisoft.de:
SRPM in ersten Schritt. Damit der Benutzer die Wahl zwischen tgz und rpm hat. (Download bei sourceforge)
Das .src.rpm wird, sofern rpmbuild nicht -bb übergeben wird, beim Bauen des Binär-RPMs automatisch mitgebaut.
Irgendwie erscheint mir der Thread klein bisschen durcheinander. Schmeiss ich mal mein Halbwissen noch dazu. RPM baut aus "SourcePackages" "RPMS" (auch: Binär-RPMs). SourcePackage ist entweder ein SRPM /oder/ ein tar mit SPEC file. Man hat also nicht etwa beides. Früher mochte man immer SRPMs, bis man merkte, dass es ja reicht, ein SPEC files ins TGZ zu werfen - von details wie Zusatzpatchen mal abgesehen. Per default sollte -tb also kein SRPM bauen (jedenfalls bei älteren SuSEs nicht ;)). Was möchtest Du nu genau machen? a) Du möchtest Deine Sourcen so distributieren, dass man ein leicht ein RPM bauen kann --> source.tgz mit SPEC file b) Du möchtest aus nicht näher genannten Gründen zusätzlich ein Source-RPM --> SPEC file, SOURCES in die entsprechenden Verzeichnisse rpm(build) -bs (Das RPM muss "funktionieren", also z.B. ohne Fehler %install können) c) Du möchtest einfach nur Sourcen und RPMs --> source.tgz mit SPEC file (Geht mit und ohne RPM, also flexibel) --> RPM (binäre) aus installierten Sourcen über %files und %install So. RPM hat folgende Idee: es wird über ein SPEC file beschrieben: - wie man von sourcen zum programm kommt (prep, build, install) - welche Files des Ergebnisses wohin kommen, welche Scripte, ob Pfade relozierbar sind oder nicht (RPM kann nicht nur absolute Pfade, kann man RPMs bauen, die man später irgendwo hin installieren kann (--prefix/--relocate), neuere RPM Versionen scheinen hier noch flexibler zu sein) - wie zu deinstallieren ist Normalerweise werden SRPMs überhaupt nicht als installiert gekennzeichnet, können nicht deinstalliert werden und sind überhaupt nur ein Hilfsmittel (natürlich ein wichtiges, wenn man einfach patchen möchte). Wie das mit %install und %files funkioniert, wurde ja auch schon schön erklärt. Ein RPM oder SPEC file ohne %install und %files ist IMHO recht sinnlos (von Spezialfällen abgesehen, da gibt's einige, wie immer :)): oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
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 .... der User hat die Sourcen installiert und in der RPM-Datanbank, das bringt ihm gar nichts. Mit nem .src.rpm hat das nämlich gar nichts zu tun, das wird beim bau eines binary RPMs normal mitgebaut (rpbuild -ba <specfile>).
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.
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.
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.
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.
%files %defattr(-,root,root) /* .......
Und dann nichts in %files ?
Nochmal genau hinschauen, da steht "/*", das ist mehr wie nichts, genau genommen das Gegenteil von nichts -> alles.
Das mit dem configure script könnte ich erst mal mit einem dummy realisieren. (Mit einer Warnung)
Las %configure einfach weg, ich hab für Packman diverse Pakete gebaut, die kein ./configure verwenden, lxdvdrip ist z.B. so ne Sache, da gibt es kein ./configure und kein make install, welches das machen würde, was ich mir wünsche (deshalb schieb ich die nötigen Dateien mit install rüber), da schaut die Sache z.B. so aus (ich las die Patches mal weg): %prep %setup -n %{name} %build export CFLAGS="$RPM_OPT_FLAGS" export CPPFLAGS="$RPM_OPT_FLAGS" %{__make} %{__make} -C vamps %install [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} %{__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 %clean [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot} %files %defattr(-, root, root) %doc doc-pak/* %config(noreplace) %{_sysconfdir}/lxdvdrip.conf %{_bindir}/*
rpm -i hat ja nichts gemacht. rpm -qlp zeigte die Dateien an und rpm -Uvh hat die tgz Datei wieder an Ihren Platz in /usr/src/packages/SOURCES gelegt.
Du installierst die src.rpm Datei? Was sonst sollte die machen, außer den Tarball und das spec File zu installieren?
Das ist erst Mal gut so. Was fehlte, war ein korrekter rpm Befehl :-)
Wenn ich denn mal alles richtig gemacht habe, ist dann ein rpm -i nur für RPM's und nicht für SRPM's gedacht ?
Nö, kann für beides verwendet werden, allerdings enthält... siehe oben. Ein Source-RPM soll ja eigentlich in ein Binary-RPM umgewandelt werden (rpmbuild --rebuild) und ist für sonst nix gut.
Denn mit SRPM's habe ich nicht mal als Benutzer zu tun gehabt. Immer nur Yast :-(
Damit kann ein Benutzer normalerweise ja auch nichts anfangen, der will ne lauffähige Version und die ist im binary-rpm. Selbst Sourcen, die installiert werden (z.B. Kernel-Sourcen) sind ja in einem binary-RPM. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am 20 Dec 2005 um 21:18 hat Manfred Tremmel geschrieben:
Damit kann ein Benutzer normalerweise ja auch nichts anfangen, der will ne lauffähige Version und die ist im binary-rpm. Selbst Sourcen, die installiert werden (z.B. Kernel-Sourcen) sind ja in einem binary-RPM.
Ja da laust mich doch der Affe :-) Ich dachte, dass eine source.tgz Distribution nicht alles ist, was ein Entwickler bereitstellt. Unter Windows habe ich auch Binary Versionen bereitgestellt. Dies wollte ich auch unter Linux und dann Mac realisieren. Im Endeffekt will ich nur, dass ein einfaches installieren möglich ist. Ich bin wohl in die Beschreibung von SRPM's reingestolpert, da ich mir offensichtlich auch solche spec's angesehen habe. (Allgemeine Verwirrung über zu viele Möglichkeiten mit RPM) Also was ich möchte ist folgendes: Ein Binary RPM, das meine Programme und nötigen Shared Libraries installiert. Dabei die Abhängigkeiten aufgelöst werden und ODBC Datenquellen für eine Demo Datenbank (PostgreSQL/MySQL) eingerichtet wird. Inclusive Treiber. Ein RPM, das meine Quellen irgendwo installiert, damit der Benutzer später alles übersetzen kann. (S-RPM/B-RPM/ oder was auch immer - ist mir egal) Dabei die Abhängigkeiten aufgelöst werden und ODBC Datenquellen für eine Demo Datenbank (PostgreSQL/MySQL) eingerichtet wird. Inclusive Treiber. Naja, eben einen besseren Anreiz, mein Projekt mal zu installieren und zu testen. (Zwecks Feedback, bisher habe ich nur Downloads und das reicht mir nicht) Danke, Lothar -- Lothar Behrens | Rapid Prototyping ... Rosmarinstr 3 | 40235 Düsseldorf | www.lollisoft.de
(Nach dem Schreiben dieser Mail fiel mir auf, dass wir vom Linuxthema ganz schön weg sind. Aber vermutlich habt ihr die Mail mit dem Subject dann eh schon gelöscht :-)). * lothar.behrens@lollisoft.de wrote on Wed, Dec 21, 2005 at 00:01 +0100:
Ich dachte, dass eine source.tgz Distribution nicht alles ist, was ein Entwickler bereitstellt.
Na ja, man kann ein SPEC mit in source.tgz packen, gar nichts zu RPM tun und/oder SRPM/RPM anbieten :-)
Also was ich möchte ist folgendes:
Ein Binary RPM, das meine Programme und nötigen Shared Libraries installiert. Dabei die Abhängigkeiten aufgelöst werden und ODBC Datenquellen für eine Demo Datenbank (PostgreSQL/MySQL) eingerichtet wird. Inclusive Treiber.
Ein RPM, das meine Quellen irgendwo installiert, damit der Benutzer später alles übersetzen kann. (S-RPM/B-RPM/ oder was auch immer - ist mir egal) Dabei die Abhängigkeiten aufgelöst werden und ODBC Datenquellen für eine Demo Datenbank (PostgreSQL/MySQL) eingerichtet wird. Inclusive Treiber.
Gut. Also sicherheitshalber nochmal: Für beide RPMs brauchst du ein (1) SPEC file. Wenn Du das in /usr/src/packages/SPECS hast (und der Rest stimmt), baut Dir rpmbuild -ba /beide/ RPMs mit den in den vorherigen Mails beschriebenen Eigenschaften. Wenn Du eine source.tgz Distribution hast, ist ein SRPM sozusagen "redundant" zu source.tgz-mit-SPEC-file-drin, macht also nur begrenzt Sinn, beides zu haben (IMHO ist ein source.tgz-mit-SPEC-file-drin auch bequemer: muss ich nicht installieren und dann das SPEC file suchen und dann an rpmbuild übergeben, sondern kann ich gleich rpmbuild -tb s.tgz machen). "fremde" Shared libraries zu installieren ist IMHO falsch, dann lieber eigene RPMs. Ist sonst nachher wie bei Windows, wo jedes WORD erstmal ne mfc.dll mitbringen muss... ODBC Datenquellen und Demo Datenbank einrichten finde ich gemein. Das klingt nach "root-Recht Missbrauch", "Easteregg" oder so. Gut, falls es denn gar keine /etc/odbc.ini oder so gibt, eine anlegen darf sich IMHO ein unixODBC.rpm erlauben - aber bitte keine Applikation. Und Demo-Datenbank einrichten? Sicherheitshalber noch einen Admin Users ins Postgres, damit das Erzeugen auch bestimmt klappt, ohne Passwort natürlich, damit das Script automatisch läuft? Da würde ich mich erst extrem wundern, welcher Hacker in meiner Datenbank gespielt hat und mich dann mächtig ärgern, wenn ich es herausfünde! Übrigens kenn ich ein produktives System, welches als DSN "demo" benutzt. Also keine Annahmen machen :-) Dann lieber ein script nach $d/doc oder $d/sbin oder so und im Programm fehlende Tabellen sauber abfangen: Die Tabelle myPkgVersion konnte nicht gefunden werden. Vermutlich ist die angeschlossene Datenquelle myDSN ($techinfo) für die Verwendung von myPkg nicht vorgesehen oder geeignet. Der Dokumentation liegt ein Datenbankerzeugunsscript und detailte Erklärungen bei. oder sowas. Wie "inklusive Treiber"? Das RPM kann ja gar nicht wissen, welche Datenbank ich verwenden möchte. Vielleicht ist MicroSoft SQL 7 (gut, nicht wirklich ne Datenbank, aber gibt Leute, die nehmen sowas) und dafür gibt es überhaupt keinen (direkten) Treiber. Vielleicht ist lokal oder remote ein PostgreSQL verfügbar, was ich aber nicht nehmen möchte/kann/darf. Vielleicht installiere ich das Packet auch nur mal auf meiner Workstation, weil ich eine lokale Installation der Dokumentation möchte (gut, wir haben daher package-doc.rpms eingeführt, aber Du weisst ja, wass ich meine). Beim Source-RPM ist das IMHO noch viel falscher. Vielleicht wollte ich mir ja bloss mal Deinen tollen Suchalgorithmus angucken oder so, und hab gar keine Datenbank. Leg doch ein Script ab, was alles macht, wenn man möchte, gebe beim installieren einen deutlichen Hinweis darauf ab und lass den Admin entscheiden :)
Naja, eben einen besseren Anreiz, mein Projekt mal zu installieren und zu testen. (Zwecks Feedback, bisher habe ich nur Downloads und das reicht mir nicht)
Hab mir mal kurz die Webseiten angeschaut. Ein Framework, also eine lib, ja? Dann hängt doch die Datenstruktur davon ab, was ich machen möchte? Ich denke, Du hast eine Demoapplikation mit im RPM, die das alles braucht, ja? Da Du Dich an Entwickler wendest (?), liege ich wohl in der Zielgruppe. Ich würde mir lieber viele kleine Scripte und so wünschen, damit ich in aller Ruhe - und Schritt für Schritt - alles ausprobieren kann. Erstmal lege ich mir (per Script) ein paar Tabellen in meiner Testdatenbank an. Da kann ich auch gleich mal Daten aus Testtabellen 'rüberselekten. Dann spiele ich vielleicht mit der DemoApp rum. Hier hab ich vermutlich ein Problem: wenn ich das binary RPM installiere, hab ich die libs. Vermutlich sind auch die header drin (oder Du hast ein -devel, auch egal). Aber wo sind die Demo-Sourcen? Würde ich auch mit reinpacken (ins binary RPM), sollte man natürlich bauen können. Vielleicht ein Unter_source.tgz, welches im source.tgz mit drin ist, bei %install kopiert wird und damit im binär RPM mit drin ist (in doc oder so). Prolog installiert z.B. /usr/lib/pl-5.0.10/dotfiles seh ich hier gerade an einer Shell. Komische Pfade, aber geht auch :) Damit sind lib und DemoApp logisch getrennt, sowas finde ich immer prima und wichtig. Und ich kann mir aussuchen, wo ich die DemoApp bauen möchte. Das schwankt bei mir je Server. Hab sogar Maschinen, da bau ich in /local/tmp (weil da halt Platz ist). So hätte ich alles schön flexibel und würde denke: Mensch, so ein flexibles, sauberes installieren, so schöne Doku, da ist das Framework bestimmt auch prima :) BTW noch ein paar Kommentare, weil Du ja feedback wolltest :) http://www.lollisoft.de/projects/dmf/firstsample.html #includes fehlen im Beispiel lbErrCodes err = ERR_NONE; Empfehle immer modul-Prefixe oder wenigestens namespaces. ERR_NONE kann auch gut von anderer Package definiert werden. Beruflich hab ich mit verschiedenen Libs zu tun, und öfter mal clashes in der Art. lbErrCode ist prima, wenn "lb" die Package ist. lb_I_Module* mm = NULL; mm = getModuleInstance(); sollte in C++ lb_I_Module *mm(getModuleInstance()); oder noch besser lb_I_Module *mm(Module::getInstance()); heissen (IMHO). Ich erwarte ein Singelton. mm->setModuleManager(mm, __FILE__, __LINE__); sowas machen wir in C oft über Macros in der Art #define setModuleManager(mm) setModuleManager_(mm, __FILE__, __LINE__) Die Implementierung hat setModuleManager_(void*, const char *const fileName, int lineNo); oder so, der Aufrufer schreibt aber nur setModuleManager(mm); find ich recht komfortabel. _CL_LOG << "Hello world" LOG_ UAP_REQUEST(mm, lb_I_String, string) mmmm... Sicherlich Geschmacksache, aber UAP_REQUEST würde ich klein schreiben (ob's ein #define ist ist IMHO Implementierungsdetail und kann sich ändern). "_" vorn mmm... Am meisten stören mich die fehlenden ";". Hatte die nach dem Kopieren oben auch schon "automatisch" gesetzt. Ich bin halt gewohnt, ";" zu schreiben, würde das lieber nicht im Macro haben wollen. string->setData("Console logging..."); _CL_LOG << string->charrep() LOG_ versteh ich nicht. string ist nicht deklariert. Was ist das? Muss es ausgerechnet string heissen? Da denke ich immer an std::string. Wenn std::string gemeint ist, sollte man das IMHO auch schreiben. Obwohl "use namespace std;" in .cc Files natürlich erlaubt ist (und in .h Files absolut verboten!), klar, aber steht da ja nicht. Das Beispiel sollte kompilieren, falls man C&P verwendet, denke ich. "In fact, it is cout." (BTW; da war ein k) Ist _CL_LOG wirklich std::cout? Dann geht also sowas wie _CL_LOG << std::hex << static_cast<int>(myVar) << LOG_ ja? LOG_ ist IMHO prädestiniert für Clashes, viel zu allgemein --> gefährlich. "To get any instance for an interface, you need to request for that interface. UAP_REQUEST is a macro and hides some code. " Mal ganz ehrlich: Ich würde keine lib nehmen, die vor mir (dem Entwickler) "some code" verstecken würde! Was passiert da? Deklarationen? Wer gibt den Speicher frei? Sind es Referenzen, kann ich die Dinger tief und/oder flach kopieren? Kann ich UAP_REQUEST(mm, lb_I_String, string) UAP_REQUEST(mm, lb_I_String, string) schreiben oder ist dann ein Bezeichner/irgendwas doppelt? Was bedeutet das überhaupt? Geht ein UAP_REQUEST(mm, lb_I_String, string) { UAP_REQUEST(mm, lb_I_String, string) } oder nicht? usw. Auch bei virtual char *LB_STDCALL getDBName ()=0 Ich kriege einen non-const-Pointer? also kann ich dbName über get ändern? Muss ich free, delete oder delete[] oder gar nichts mit dem Rückgabewert machen? virtual const string& getDBName(void) const = 0; wäre IMHO eindeutiger: ich kann halt den String nur maximal kopieren aber "nichts kaputt machen" und muss auch nicht mit Zeigern handtieren. Allerdings hab ich noch nicht verstanden, was die lib mir genau bietet. Ist es eine ODBC-Zugriffs lib wie die (IMHO recht gute) http://libodbcxx.sourceforge.net/ ? Die hat auch ein recht nettes Memorymanagement, find ich. Ich hoffe, ich konnte ein bisschen helfen. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hallo, Am Wed, 21 Dec 2005, lothar.behrens@lollisoft.de schrieb:
Also was ich möchte ist folgendes:
Ein Binary RPM, das meine Programme und nötigen Shared Libraries installiert.
Shared-Libs solltest du nie mit ins System installieren, installiere sie lokal (wie z.B. Mozilla) und sorge mit wrapper-scripten dafuer, dass sie gefunden werden, oder besser, linke diese Libs statisch. Oder setz die Libs per "Requires: " (s.u.) voraus.
Dabei die Abhängigkeiten aufgelöst werden und ODBC Datenquellen für eine Demo Datenbank (PostgreSQL/MySQL) eingerichtet wird. Inclusive Treiber.
Demos gehoeren nach %{_docdir}/%{name}-%{version}/examples oder %{_docdir}/%{name}-%{version}/demo. Und zwar als binary mit Quelltext. Und zwar im -devel RPM.
Ein RPM, das meine Quellen irgendwo installiert, damit der Benutzer später alles übersetzen kann. (S-RPM/B-RPM/ oder was auch immer - ist mir egal) Dabei die Abhängigkeiten aufgelöst werden und ODBC Datenquellen für eine Demo Datenbank (PostgreSQL/MySQL) eingerichtet wird. Inclusive Treiber.
Das waere ein SRPM, da kann der Installierende ueber %_topdir definieren
wo der tarball+spec ausgepackt werden sollen. Kannst du ja
dokumentieren:
==== ~/.rpmmacros ====
%_topdir ~/src/packages
====
Der Installierende muss halt ggfs. vorher ein:
for d in BUILD RPMS SOURCES SPECS SRPMS; do
install -d -m 750 ~/src/packages/${d}
done
aufrufen.
Folgendes .spec Geruest ergibt sich also:
==== UNGETESTET ====
[PRAEAMBEL]
Prefix: /usr/local
BuildRequires: [was man zum kompilieren des SRPMS braucht]
Requires: [was man zum installieren der fertigen binaries braucht]
%package devel
Requires: %{name} = %{version}
Requires: [was man zum kompilieren mit deiner lib braucht, z.B. \
-devel RPMs der benoetigten libs, da du deren Header einbindest]
BuildRequires: [was man zum kompilieren des SRPMS braucht]
%prep
%setup -q
%build
# ggfs. configure o.ae.
make ... # wie deine Binaries kompiliert werden muessen
%install
# wie deine Binaries kompiliert installiert werden muessen:
make DESTDIR="%{buildroot}" install
### NIE ins System installieren! Ggfs. setze beim 'make install' eben
### z.B. make prefix="%{buildroot}%{prefix}"
%post
cat <
David Haller schrieb:
Shared-Libs solltest du nie mit ins System installieren, installiere sie lokal (wie z.B. Mozilla) und sorge mit wrapper-scripten dafuer, dass sie gefunden werden, oder besser, linke diese Libs statisch.
Wenn es wirklich ein Framework ist, sprich die Bibliotheken von anderen für ihre Programme benutzt werden sollen, macht das Obige keinen Sinn. Philipp
Hallo, Am Thu, 22 Dec 2005, Philipp Thomas schrieb:
David Haller schrieb:
Shared-Libs solltest du nie mit ins System installieren, installiere sie lokal (wie z.B. Mozilla) und sorge mit wrapper-scripten dafuer, dass sie gefunden werden, oder besser, linke diese Libs statisch.
Wenn es wirklich ein Framework ist, sprich die Bibliotheken von anderen für ihre Programme benutzt werden sollen, macht das Obige keinen Sinn.
Aeh, klar, die eigenen Libs des Frameworks schon. Aber eben keine anderen. Vgl. es wuerde im krassesten Fall jede App ihre eigene libc mitinstallieren... und in /lib/ ablegen... -dnh -- 18: Vorbereitet für den Multimediaeinsatz Es sind noch zwei Slots auf dem Motherboard frei. (Peter Berlich)
* 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.
Hallo, Am Wed, 21 Dec 2005, Steffen Dettmer schrieb: [..]
%files %defattr(-,root,root) /* .......
Und dann nichts in %files ?
Das war ein Witz. Bitte keine derartigen RPMs versuchen. Niemals installieren. Und vorallem: niemals deinstallieren :-)
Probier's. Mit /tmp/bla/. BTDT. Ist aber WIRKLICH eine extrem BLOEDE Idee, denn dann meint RPM, die Verzeichnisse /usr/bin gehoeren z.B. zum Paket foo anstatt aaa_base (oder so). Deswegen immer nur die Verzeichnisse, die wirklich zum Paket gehoeren angeben. %{_bindir}/* geht, damit werden alle Dateien in %{buildroot}%{_bindir} eingesammelt. %{_libdir}/foo/* ist schlecht, denn dann gehoert %{_libdir}/foo zu keinem RPM, dann also entweder: %dir %{_libdir}/foo %{_libdir}/foo/* oder %{_libdir}/foo Generell sollte man RPMs immer erstmal mit 'rpm --test -[iUF]vv' antesten und schauen was genau mitkommt. Andere Optionen wie '--nodeps' und '--force' sollte man nur nehmen, wenn man GENAU weiss was Sache ist. Ich mach obiges sogar mit den eigenen RPMs! Und z.B. '--nodeps' verwende ich nur selten, wenn ich z.B. eine Abhaengigkeit auf libbar.so.0 habe, aber diese eine lib eben ohne RPM installiert habe und zu faul bin, die lib in ein RPM zu packen. Und eben nur, wenn es genau die Abhaengigkeit zu libbar.so.0 ist. Manchmal back' ich aber auch "mal eben" ein dummy-RPM mit den passenden Requires/Provides. Um da aber kein Chaos anzurichten sollte man schon ziemlich genau wissen wie RPM funktioniert. Und das scheint mir bei Lothar noch nicht der Fall zu sein, also Lothar, Haende weg von solchen Tricks ;)
Nochmal genau hinschauen, da steht "/*", das ist mehr wie nichts, genau genommen das Gegenteil von nichts -> alles.
(Müsste das nicht nur "/" heissen?)
Ja. Den der Glob '/*' passt nicht auf '/.*'.
%{__make}
Standard RPM-Macro?
Ja.
%install [ "%{buildroot}" != "/" ] && %{__rm} -rf %{buildroot}
Auch Standard RPM?
Ja. Schau dir /usr/lib/rpm/macros (und /usr/lib/rpm/suse_macros) an. Wenn du magst kann ich dir auch die passenden Makro-Dateien meiner SuSE 6.2 mit rpm 3.0.4 mailen, so als Referenz was man "sicher" voraussetzen kann. Ist teilweise signifikant anders als z.B. unter SuSE 9.1 ;) Achso, auch /etc/rpm* sollte man sich mal anschauen. -dnh PS: ich hab sogar ein eigenes "macro"-file in /etc/rpm/ um das passende Verzeichnis von (X)Emacs fuer lisp-Dateien herauszufinden, ist aber noch nicht wirklich ausgereift... --
Take two Gods. Diagnostic. n. Someone who doubts the existence of two Gods. Makes sense. Every regular user of diagnostics that I know of only believes in Murphy. -- >>D. Holdsworth, >C. Suslowicz and Lionel
participants (7)
-
Christian Boltz -
David Haller -
lothar.behrens＠lollisoft.de -
Manfred Tremmel -
Philipp Thomas -
Philipp Thomas -
Steffen Dettmer