Ist RPM wirklich so schlecht?
Hi, ich wollte letzte Woche einige Pakete bauen. Leider stellte ich relativ schnell fest das RPM (zumindest das was bei SuSe 8.2 dabei ist) sagen wir nicht das gelbe vom Ei ist (milde gesagt). - Pakete müssen als root gebaut werden - So bald sie *.spec Datei einen Owner oder Gruppe hat die nicht local vorhanden sind und die Authentifizierung über LDAP läuft verabschiedet sich RPM ganz schnell mit einem SIG-Fault. Die Frage an dieser Stelle, ist das wieder eine Besonderheit von SuSE oder doch eine RPM schwachstelle? Pozdrawiam/Gruß/Regards Robert Rakowicz -- Robert Rakowicz E-Mail: b9001@rjap.de URL: www.rjap.de
Robert Rakowicz schrieb: Moin,
ich wollte letzte Woche einige Pakete bauen. Leider stellte ich relativ schnell fest das RPM (zumindest das was bei SuSe 8.2 dabei ist) sagen
kann sein, daß das am Preview-Status der SuSE 8.2 liegt. BTW: wo bekommt man die? ;-)
Die Frage an dieser Stelle, ist das wieder eine Besonderheit von SuSE oder doch eine RPM schwachstelle?
also, soweit ich weiß, verwendet RED HAT mittlerweile eine neuere Version von RPM. Ich kann aber auch nicht, ob die in SuSE oder in RED HAT eingesetzte Version besser / schlechter ist. bis denn ... /Frank/
On Sun, Mar 09, 2003 at 10:13:58PM +0100, Frank Röske wrote:
also, soweit ich weiß, verwendet RED HAT mittlerweile eine neuere Version von RPM. Ich kann aber auch nicht, ob die in SuSE oder in RED HAT eingesetzte Version besser / schlechter ist.
RedHat verwendet RPM 4. Das unterscheidet sich sehr weitgend von RPM 3.x das bei SuSE eingesetzt wird, unter anderem dadurch, daß eine Menge Funktinalität in weitere Programme ausgelagert worden ist - rpm zur Installation, rpmq zur Abfrage der rpmdb, und rpmbuild als Paketbautool. Kristian
Hi, On Sunday 09 March 2003 20:06, Robert Rakowicz wrote:
Hi,
ich wollte letzte Woche einige Pakete bauen. Leider stellte ich relativ schnell fest das RPM (zumindest das was bei SuSe 8.2 dabei ist) sagen
Wo hast du die SuSE 8.2 her?
wir nicht das gelbe vom Ei ist (milde gesagt). - Pakete müssen als root gebaut werden
Das kommt drauf an, wie das spec-File aussieht. Pakete muessen nicht notwendigerweise als root gebaut werden.
- So bald sie *.spec Datei einen Owner oder Gruppe hat die nicht local vorhanden sind und die Authentifizierung über LDAP läuft verabschiedet sich RPM ganz schnell mit einem SIG-Fault.
Die Frage an dieser Stelle, ist das wieder eine Besonderheit von SuSE oder doch eine RPM schwachstelle?
Dazu kann ich nix sagen. Ciao
Am Sonntag, 9. März 2003 20:06 schrieb Robert Rakowicz:
ich wollte letzte Woche einige Pakete bauen. Leider stellte ich relativ schnell fest das RPM (zumindest das was bei SuSe 8.2 dabei
Darf man fragen, wo Du ne SuSE 8.2 her hast?
ist) sagen wir nicht das gelbe vom Ei ist (milde gesagt). - Pakete müssen als root gebaut werden
Nein. Ich bastle meine RPMs eigentlich alle als user (ein paar ausnahmen, wie sane, das kein destdir bei make install schluckt mal abgesehen).
- So bald sie *.spec Datei einen Owner oder Gruppe hat die nicht local vorhanden sind und die Authentifizierung über LDAP läuft verabschiedet sich RPM ganz schnell mit einem SIG-Fault.
Nagut, über LDAP läuft hier nichts, keine Ahnung, ob das ein spezielles Problem ist. Den zu erstellenden RPMs sollte man in jedem Fall %defattr im SPEC-File mitteilen, dass sie als User root haben. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Am Sonntag, 9. März 2003 22:19 schrieb Manfred Tremmel:
Nein. Ich bastle meine RPMs eigentlich alle als user (ein paar ausnahmen, wie sane, das kein destdir bei make install schluckt mal abgesehen).
Den zu erstellenden RPMs sollte man in jedem Fall %defattr im SPEC-File mitteilen, dass sie als User root haben.
hm... was genau hast du dafür wo wie umgestellt? chown -R wheel /usr/src/packages; chmod -R g+w /usr/src/packages; und dann deinen user in die gruppe wheel rein? oder wie? bye, [MH] -- Die unaufgeforderte Zusendung einer Werbemail an Privatleute verstößt gegen §1 UWG und §823 I BGB (Beschluß des LG Berlin vom 2.8.1998 Az: 16 O 201/98). Jede kommerzielle Nutzung der übermittelten persönlichen Daten sowie deren Weitergabe an Dritte ist ausdrücklich untersagt!
Am Sonntag, 9. März 2003 22:26 schrieb Mathias Homann:
hm... was genau hast du dafür wo wie umgestellt? chown -R wheel /usr/src/packages; chmod -R g+w /usr/src/packages; und dann deinen user in die gruppe wheel rein? oder wie?
Ich war da radikaler. Da ich den Rechner eh allein nutze, lief ein 'chmod -R 777 /usr/src/packages' drüber. Habe keine Lust mir etwas im System kaputt machen zu lassen von nem kaputen Make- oder SPEC-file. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
Manfred Tremmel
Nein. Ich bastle meine RPMs eigentlich alle als user (ein paar ausnahmen, wie sane, das kein destdir bei make install schluckt mal abgesehen).
O.K dann wird es wohl daran liegen das die User aus dem LDAP kommen. Nicht schön ;( Pozdrawiam/Gruß/Regards Robert Rakowicz -- Robert Rakowicz E-Mail: b9001@rjap.de URL: www.rjap.de
Hallo, On Sun, 09 Mar 2003, Manfred Tremmel wrote:
Nein. Ich bastle meine RPMs eigentlich alle als user (ein paar ausnahmen, wie sane, das kein destdir bei make install schluckt mal abgesehen).
Hoeh? Ich backe _alle_ RPMs als User. Auch sane. sane-backends-1.0.8.spec: make DESTDIR="${RPM_BUILD_ROOT}" install sane-frontends-1.0.8.spec: make DESTDIR="${RPM_BUILD_ROOT}" install Und nein, ich habe die Makefiles nicht gepatcht. Bei anderen Paketen mach ich das ab und an oder installiere eben mit make prefix="${RPM_BUILD_ROOT}%{prefix}" install -dnh -- Man sagt ja immer : " Der dümmste Bauer hatt die dicksten Kartoffeln!" Dann müsste es in meinem Fall doch heissen : "Das dümmste Woko hatt die besten Wognaturen." Das würde denn aber beweisen das Ich nicht dumm bin. Ist das jetzt ein Temporäres Paradoxon oder so was? [WoKo in dag°]
Am Dienstag, 11. März 2003 16:40 schrieb David Haller:
Hoeh? Ich backe _alle_ RPMs als User. Auch sane.
Hm, muß ich mir das nochmal ansehen. Danke für den Hinweis. -- Machs gut | http://www.iivs.de/schwinde/buerger/tremmel/ | http://packman.links2linux.de/ Manfred | http://www.knightsoft-net.de
David Haller wrote:
make DESTDIR="${RPM_BUILD_ROOT}" install
Ist das die einzige/bequemste Weise, ein "autoconf" Paket an RPM_BUILD_ROOT zu gewoehnen? Mir ist nach Maximum-RPM klar, wie ich bei handgeschriebenen Makefiles diese Varaible nutzen kann, nur bei autoconf erzeugter Buildumgebung blicke ich nicht wirklich durch. --prefix ist es nicht, da sich dieser Parameter dann in Hilfsskripten, bzw. in den executables niederschlaegt. Peter
Peter Wiersig schrieb:
David Haller wrote:
make DESTDIR="${RPM_BUILD_ROOT}" install
Ist das die einzige/bequemste Weise, ein "autoconf" Paket an RPM_BUILD_ROOT zu gewoehnen?
Autoconf hat damit nichts zu tun. Für Projekte, die Automake verwenden, bzw. alle die DESTDIR unterstützen, ist das der bequemste Weg. Jedoch muss man evtl. noch nachbessern und die möglicherweise vorhandene DESTDIR-Pfade in den installierten Dateien anpassen.
Mir ist nach Maximum-RPM klar, wie ich bei handgeschriebenen Makefiles diese Varaible nutzen kann, nur bei autoconf erzeugter Buildumgebung blicke ich nicht wirklich durch.
--prefix ist es nicht, da sich dieser Parameter dann in Hilfsskripten, bzw. in den executables niederschlaegt.
Peter
Am Die, 2003-03-11 um 21.00 schrieb Peter Wiersig:
David Haller wrote:
make DESTDIR="${RPM_BUILD_ROOT}" install
Ist das die einzige/bequemste Weise, ein "autoconf" Paket an RPM_BUILD_ROOT zu gewoehnen? DESTDIR hat mit autoconf nichts zu tun.
autoconf generiert configure-Skripte, aber keine Makefiles, DESTDIR wird ist aber eine Eigenschaft von Makefiles.
Mir ist nach Maximum-RPM klar, wie ich bei handgeschriebenen Makefiles diese Varaible nutzen kann, nur bei autoconf erzeugter Buildumgebung blicke ich nicht wirklich durch.
In handgeschriebenen Makefiles musst Du selbst für DESTDIR-Unterstützung sorgen, in Installationsregeln in von neueren automake-Versionen erzeugten Makefiles wird es automatisch eingebaut.
--prefix ist es nicht, da sich dieser Parameter dann in Hilfsskripten, bzw. in den executables niederschlaegt. Keine Ahnung, was Du hiermit ausdrücken willst.
Ralf
Ralf Corsepius wrote:
Am Die, 2003-03-11 um 21.00 schrieb Peter Wiersig:
David Haller wrote:
make DESTDIR="${RPM_BUILD_ROOT}" install
Ist das die einzige/bequemste Weise, ein "autoconf" Paket an RPM_BUILD_ROOT zu gewoehnen?
DESTDIR hat mit autoconf nichts zu tun.
autoconf generiert configure-Skripte, aber keine Makefiles, DESTDIR wird ist aber eine Eigenschaft von Makefiles.
aha, jetzt verstanden. "info make" produziert dann auch die Doku zu DESTDIR. Kapiert.
Mir ist nach Maximum-RPM klar, wie ich bei handgeschriebenen Makefiles diese Varaible nutzen kann, nur bei autoconf erzeugter Buildumgebung blicke ich nicht wirklich durch.
In handgeschriebenen Makefiles musst Du selbst für DESTDIR-Unterstützung sorgen,
laut o.g. make.info nicht, da make dann quasi das Verzeichnis als / uebernimmt. Genau was ich suchte, nur halt an der falschen Stellen. Probiere ich bei naechster Gelegenheit mal aus.
--prefix ist es nicht, da sich dieser Parameter dann in Hilfsskripten, bzw. in den executables niederschlaegt.
Keine Ahnung, was Du hiermit ausdrücken willst.
z.B. gtk-config, das dann von Drittprogrammen dazu benutzt wird um die Bibliothekspfade des Systems zu bestimmen. Wenn man gtk mit --prefix=/var/tmp/gtk-root/usr bzw. den untergeordneten --bindir, --includedir, usw. wird gtk-config auch auf /var/tmp/gtk-root verweisen. IIRC wurde die libjpeg aus SuSE 6.4 mit diesem Fehler in libjpeg.la auf CD-ROM gepresst. Peter
Am Die, 2003-03-11 um 21.41 schrieb Peter Wiersig:
Ralf Corsepius wrote:
Am Die, 2003-03-11 um 21.00 schrieb Peter Wiersig:
David Haller wrote:
make DESTDIR="${RPM_BUILD_ROOT}" install
Ist das die einzige/bequemste Weise, ein "autoconf" Paket an RPM_BUILD_ROOT zu gewoehnen?
DESTDIR hat mit autoconf nichts zu tun.
autoconf generiert configure-Skripte, aber keine Makefiles, DESTDIR wird ist aber eine Eigenschaft von Makefiles.
aha, jetzt verstanden. "info make" produziert dann auch die Doku zu DESTDIR. Kapiert.
Mir ist nach Maximum-RPM klar, wie ich bei handgeschriebenen Makefiles diese Varaible nutzen kann, nur bei autoconf erzeugter Buildumgebung blicke ich nicht wirklich durch.
In handgeschriebenen Makefiles musst Du selbst für DESTDIR-Unterstützung sorgen,
laut o.g. make.info nicht, da make dann quasi das Verzeichnis als / uebernimmt.
Hmm? Das von Dir Gesagte wäre mir neu, genauso wie das von mir verwendete gnu-make-3.79, ebenso wie alle anderen mir bekannten make's, DESTDIR nicht kennt. Ralf
Hallo, On Tue, 11 Mar 2003, Peter Wiersig wrote:
David Haller wrote:
make DESTDIR="${RPM_BUILD_ROOT}" install
Ist das die einzige/bequemste Weise, ein "autoconf" Paket an RPM_BUILD_ROOT zu gewoehnen?
Nein. Die Frage ist, ob das Makefile DESTDIR (durchgaengig!) unterstuetzt. Das ist z.B. bei automake-generierten Makefiles der Fall -- es sei denn, der Entwickler hat das durch eigene make-targets wieder sabotiert (ist mir schon haeufiger untergekommen)... DESTDIR ist eine ganz normale make-Variable... Falls die Makefiles DESTDIR unterstuetzen, dann ist obiges die beste Variante, ja. Die einzige ist es nicht, manche (schlechtere) .specs verwenden z.B. prefix="${RPM_BUILD_ROOT}%{prefix}" obwohl das Makefile DESTDIR unterstuetzt... Und dann gibt's noch kranke Pakete, wo weder das eine, noch das andere Funktioniert...
Mir ist nach Maximum-RPM klar, wie ich bei handgeschriebenen Makefiles diese Varaible nutzen kann, nur bei autoconf erzeugter Buildumgebung blicke ich nicht wirklich durch.
Das hat mit RPM und autoconf genau garnix zu tun.
--prefix ist es nicht, da sich dieser Parameter dann in Hilfsskripten, bzw. in den executables niederschlaegt.
Hae? ./configure hat damit auch nix zu tun. Falls DESTDIR unterstuetzt wird, dann findet sich im .spec folgendes: ==== %prep %setup -q %build CFLAGS="$RPM_OPT_FLAGS" \ ./configure --prefix=%{_prefix} make %install make DESTDIR="${RPM_BUILD_ROOT}" install ==== -dnh -- "Reality is that which, when you stop believing in it, doesn't go away". -- Philip K. Dick
Am Mit, 2003-03-12 um 02.50 schrieb David Haller:
Hallo,
On Tue, 11 Mar 2003, Peter Wiersig wrote:
David Haller wrote:
make DESTDIR="${RPM_BUILD_ROOT}" install
Ist das die einzige/bequemste Weise, ein "autoconf" Paket an RPM_BUILD_ROOT zu gewoehnen?
Nein. Die Frage ist, ob das Makefile DESTDIR (durchgaengig!) unterstuetzt. Das ist z.B. bei automake-generierten Makefiles der Fall -- es sei denn, der Entwickler hat das durch eigene make-targets wieder sabotiert (ist mir schon haeufiger untergekommen)...
DESTDIR ist eine ganz normale make-Variable...
Falls die Makefiles DESTDIR unterstuetzen, dann ist obiges die beste Variante, ja. Die einzige ist es nicht, manche (schlechtere) .specs verwenden z.B. prefix="${RPM_BUILD_ROOT}%{prefix}" obwohl das Makefile DESTDIR unterstuetzt... Irrtum, make prefix=${RPM_BUILD_ROOT}%{prefix} ist nicht eine schlechtere Variante, sondern eine flexiblere, ältere und weiter verbreitete Variante, die in komplexen Installationen notwendig wird, nur im Fall von RPM in der Regel nicht benötigt wird.
Hintergrund: * Fast alle Pakete unterstützten "make prefix=...", da auch fast alle nicht mit automake und mit älteren automakes erstellten Pakete $prefix ($bindir, $includedir etc) kennen (Oftmals ohne dass es die Autoren wissen). DESTDIR hingegen ist relativ neu und wurde erst im Zusammenhang mit dem Aufkommen von RPM populär, ist aber auf Nicht-Linux-Systemen oft nicht anwendbar. * In Netzwerk-Installationen ist "make prefix=..." oft notwendig, da dort das bei der Konfiguration übergebene Verzeichnis oft nicht mit dem Verzeichnis übereinstimmt, unter dem Nutzer Programme/Dateien/Libs verwenden. Ralf
hallo, über yast ist dial-on-demand konfiguriert. das funktioniert auf den ersten blick auch (ich benutze kinternet ). ich habe ein datenabonnement, das ich über das internet empfange. dadurch dürfte es keine inaktivität geben. trotzdem komme ich oft an den rechner und ärgere mich darüber, dass die verbindung unterbrochen ist. sie ist nicht nur unterbrochen im sinne von kinternet's auflegen, sondern im sinne von kinternet's halt. wie kann das sein? danke, jan
participants (10)
-
David Haller -
Frank Röske -
Jan Höhn -
Kristian Koehntopp -
Manfred Tremmel -
Mathias Homann -
Peter Wiersig -
Ralf Corsepius -
Robert Rakowicz -
Sebastian Huber