rpm Pakete selber erstellen

[linuxstarter34]

Ich möchte selber ein rpm-Paket erstellen. Da ich aber in Linux noch nicht so fit bin, schaffe ich es einfach nicht. Ich habe mich schon mit den manuals und diversen Internetseiten geschäftigt, komme aber irgendwie nicht zum Ziel.

Was möchte ich machen?
Ich habe z.B. 3 Configfiles und 2 Shellskripte, die ich in ein RPM-File verpacken möchte. Die 5 Dateien sollen z.B. nach /tmp/INSTALL/ kopiert werden und danach die beiden Shellskripte ausgeführt werden. Bisher habe nicht einmal ansatzweise geschafft.

Hat hier jemand Ideen, wie das funktionieren könnte?

[Rain_maker]

http://www.google.com/search?client=opera&rls=de&q=RPM+erstellen&sourceid=opera&ie=utf-8&oe=utf-8

Da war nichts passendes dabei?

Allgemein:



man rpmbuild

Für Notfälle "checkinstall" (Quick and Dirty).

GUI für erste Schritte:

krpmbuilder

Greetz,

RM

[reni]

Das sollte helfen:
http://www.tu-chemnitz.de/docs/lindocs/RPM/node12.html

[Rain_maker]

Ist sicher nützlich, aber leider schon etwas älter, was man an den Kommandos sieht.

z.B.



rpm --rebuildist obsolet, die "neue" Syntax wäre:



rpmbuild --rebuildAlso ist eben etwas Mitdenken angesagt, wenn man das auf eine neue Distri anwenden will.

Greetz,

RM

[linuxstarter34]

Danke für die Tipps, aber diese Manuals habe ich alle schon hinter mir.
Ich habe keine rpm-Teile die mit configure, make, make install kompiliert oder installiert werden
müssen.

Ich habe jediglich ein paar Files und ein paar Shellskripte die ich in ein rpm-Paket verpacken
möchte und bei der späteren installation an eine beliiebige Stelle im System installieren,
bzw. ausführen möchte.

Kann das rpm überhaupt ? Sorry aber ich habe nicht viel Ahnung davon. Und ich habe keine Ahnung wie da das SPEC-File für die Erstellung aussehen muss, damit sowas klappt.

Sorry für mein Nichtwissen und Danke schon im vorraus für eure Hilfe

linuxstarter34

[Rain_maker]

Ich habe jediglich ein paar Files und ein paar Shellskripte die ich in ein rpm-Paket verpacken
möchte und bei der späteren installation an eine beliiebige Stelle im System installieren,
bzw. ausführen möchte.

Umso einfacher, dann braucht es nur den "install"- und den "files"-Teil des SPECs, die Teile zu configure und make einfach weglassen.

Ich geb Dir mal ein solches SPEC als "Anschaungsmaterial":



%define name rt61-rt73-legacy-firmware
%define version 1.0
%define release 1

Summary: Firmware files for Ralink-Cards with rt61/rt73 chip in combination with the rt61/73-legacy-drivers from the Serialmonkey-Project

Name: %{name}
Version: %{version}
Release: %{release}
Source0: rt61-rt73-legacy-firmware-1.0.tar.bz2
License: Proprietary
Group: System/Kernel and hardware
Url: http://web.ralinktech.com/ralink/Home/Support/Linux.html
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-buildroot

%description
This package contains the firmware files for Ralink-Cards with rt61/rt73 chip in Combination with the rt61/73-legacy-drivers from the Serialmonkey-Project. The firmware files will be copied to /lib/firmware.

%prep
%setup -q -n %{name}

%build

%install
rm -rf $RPM_BUILD_ROOT
install -d $RPM_BUILD_ROOT/etc/Wireless/RT73STA
install -d $RPM_BUILD_ROOT/etc/Wireless/RT61STA
install -m644 rt73* $RPM_BUILD_ROOT/etc/Wireless/RT73STA
install -m644 rt2* $RPM_BUILD_ROOT/etc/Wireless/RT61STA

%clean
rm -rf $RPM_BUILD_ROOT

%files
%defattr(-,root,root)
/etc/Wireless/RT61STA/rt2*
/etc/Wireless/RT73STA/rt7*

So in etwa sollte das aussehen, wie man sieht ist der Teil zu "%build" leer.

Greetz,

RM

[gropiuskalle]

Für Notfälle "checkinstall" (Quick and Dirty).

Erkläre doch mal, wieso Du dies so einschränkend umschreibst - checkinstall ist doch ganz wunderbar (und benutzt nebenbei ebenfalls rpmbuild). Wieso soll sich das nur für Notfälle eignen?

Edit:


GUI für erste Schritte:

krpmbuilder

Hast Du Krpmbuilder schon mal benutzt? Das Ding ist in meinen Augen absoluter Schrott, zumal seit runden zwei Jahren keine Weiterentwicklung mehr stattfindet. Abgesehen davon, dass die GUI hier eher verwirrt als unterstützt, sehe ich auch keinerlei Mehrwert in der Implemetierung einer GUI in einen Paketbauer. Nix gegen GUIs per se, aber Krpmbuilder vereinfacht das Procedere doch kein Stück.

[Rain_maker]

1. Kein src.rpm (wäre mir zumindest neu).

2. Dependencies werden oft nicht korrekt eingetragen/erkannt (oder meist vom Ersteller weggelassen).

3. Muß als root ausgeführt werden (warum eigentlich?).

4. kmp-Pakete kannst Du damit vergessen.

5. Würde hier nicht funktionieren, da es kein Makefile gibt.

Reicht das für den Anfang?

Gut zum Testen aber eben "Quick and Dirty".

Außerdem ist der Lerneffekt=0, ok ist natürlich kein besonders starkes Argument, aber als relativer Anfänger benutz(t)e ich häufig krpmbuilder, um mir ein "grobes" SPECfile erstellen zu lassen, welches man dann immer noch abändern kann.

Des Weiteren kann man durch das Lesen von "Profi"-SPECfiles (aus offizielen Paketen von SUSE/Packman/Guru/jengelh & Co.) Vieles lernen und diese dann auf seine eigenen Pakete anpassen.

Greetz,

RM

[gropiuskalle]

1. Kein src.rpm (wäre mir zumindest neu).

checkinstall kann keine davon erstellen meinst Du? Ich weiß nicht so supergenau, was ein src.rpm eigentlich macht, aber ich habe bislang auch noch nie welche bauen müssen, auf jeden Fall geht es hier im thread aber doch um reguläre .rpms, oder?


Dependencies werden oft nicht korrekt eingetragen/erkannt (oder meist vom Ersteller weggelassen).
Du liest schon noch mit, oder? checkinstall greift bei der Erstellung des Pakets auf rpmbuild zurück. Mir ist dieses Phänomen bislang noch kein einziges mal untergekommen, und ich verwende checkinstall sehr oft.


3. Muß als root ausgeführt werden (warum eigentlich?).

Warum beurteilst Du eine Anwendung, ohne damit Erfahrung zu haben? Schau mal:


kalle@hoppers:~/yakuake-2.7.5> checkinstall

Achte auf den Prompt. So geht's (gekürzt) weiter:


checkinstall 1.6.0, Copyright 2002 Felipe Eduardo Sanchez Diaz Duran
This software is released under the GNU GPL.


The package documentation directory ./doc-pak does not exist.
Should I create a default set of package docs? [y]: y

Preparing package documentation...OK

Please write a description for the package.
End your description with an empty line or EOF.
>> KDE Terminal Emulator

**************************************
**** RPM package creation selected ***
**************************************

This package will be built according to these values:

1 - Summary: [ KDE Terminal Emulator ]
2 - Name: [ yakuake ]
3 - Version: [ 2.7.5 ]
4 - Release: [ 1 ]
[...]


etc. etc.

Dann dies:


[...]
make[4]: Für das Ziel install-exec-am ist nichts zu tun.
test -z "/opt/kde3/share/apps/yakuake/default" || mkdir -p -- "/opt/kde3/share/apps/yakuake/default"
/usr/bin/install -c -p -m 644 'tabs.skin' '/opt/kde3/share/apps/yakuake/default/tabs.skin'
/usr/bin/install -c -p -m 644 'title.skin' '/opt/kde3/share/apps/yakuake/default/title.skin'
/usr/bin/install -c -p -m 644 'install.sh' '/opt/kde3/share/apps/yakuake/default/install.sh'
/usr/bin/install -c -p -m 644 'manual.readme' '/opt/kde3/share/apps/yakuake/default/manual.readme'
make[4]: Leaving directory `/home/kalle/yakuake-2.7.5/yakuake/skins'
make[3]: Leaving directory `/home/kalle/yakuake-2.7.5/yakuake/skins'
make[2]: Leaving directory `/home/kalle/yakuake-2.7.5/yakuake/skins'
make[2]: Entering directory `/home/kalle/yakuake-2.7.5/yakuake'
make[3]: Entering directory `/home/kalle/yakuake-2.7.5/yakuake'
make[3]: Für das Ziel install-exec-am ist nichts zu tun.
make[3]: Für das Ziel install-data-am ist nichts zu tun.
make[3]: Leaving directory `/home/kalle/yakuake-2.7.5/yakuake'
make[2]: Leaving directory `/home/kalle/yakuake-2.7.5/yakuake'
make[1]: Leaving directory `/home/kalle/yakuake-2.7.5/yakuake'
make[1]: Entering directory `/home/kalle/yakuake-2.7.5'
make[2]: Entering directory `/home/kalle/yakuake-2.7.5'
make[2]: Für das Ziel install-exec-am ist nichts zu tun.
make[2]: Leaving directory `/home/kalle/yakuake-2.7.5'
make[1]: Leaving directory `/home/kalle/yakuake-2.7.5'

======================== Installation successful ==========================

[...]


Man könnte anhand der Ausgabe fast denken, dass ein normaler user hier was installieren konnte, aber die Geschichte ist noch nicht fertig:


chown: Ändern des Eigentümers von ?/var/tmp/checkinstall.P14065/package//usr/share/doc/packages/yakuake-2.7.5/TODO?: Die Operation ist nicht erlaubt
chown: Ändern des Eigentümers von ?/var/tmp/checkinstall.P14065/package//usr/share/doc/packages/yakuake-2.7.5/README?: Die Operation ist nicht erlaubt
chown: Ändern des Eigentümers von ?/var/tmp/checkinstall.P14065/package//usr/share/doc/packages/yakuake-2.7.5/VERSION?: Die Operation ist nicht erlaubt[...]


etc. etc. - Dies hindert checkinstall nicht daran, folgendes zu machen:


Copying files to the temporary directory...OK

Compressing man pages...OK

Building file list...OK

Building RPM package...OK

NOTE: The package will not be installed

Erasing temporary files...OK

Deleting doc-pak directory...OK

Writing backup package...OK

Deleting temp dir...OK


************************************************** ********************

Done. The new package has been saved to

/usr/src/packages/RPMS/i386/yakuake-2.7.5-1.i386.rpm
You can install it in your system anytime using:

rpm -i yakuake-2.7.5-1.i386.rpm

************************************************** ********************

kalle@hoppers:~/yakuake-2.7.5

Dafür muss keiner root sein, deswegen ist checkinstall ja auch so praktisch - man kann etwas kompilieren, ohne es gleichzeitig installieren zu müssen.


5. Würde hier nicht funktionieren, da es kein Makefile gibt.

Das stimmt zwar, aber Du hattest checkinstall dennoch als erster in den Raum geworfen.

Den Rest lasse ich unkommentiert, weil ich nicht mal im Entferntesten weiß, was "Profi"-SPECfiles oder KMP-Pakete sind. Man kann seine Ahnungslosigkeit nämlich durchaus mal zugeben, ohne sich dabei in die Hose machen zu müssen, weil sämtliche Reputation dadurch vermeintlich flöten geht.

[Rain_maker]

which checkinstall
/usr/sbin/checkinstall(openSUSE 10.2)

Interessant, daß Du das als User ohne den absoluten Pfad aufrufen kannst. Normalerweise ist für einen normalen User /usr/sbin nicht in $PATH oder ist das ein Ubuntu? (das aber nur am Rande)

OK, schön wenns auch als User geht, das macht checkinstall aber noch lange nicht zu einer vollwertigen Lösung sondern zu dem, was ich geschrieben hatte.

Außerdem scheinst Du mit dem Wort Notlösung nicht zurecht zu kommen, eine Notlösung ist auch eine Lösung, aber eben keine vollwertige.


Du liest schon noch mit, oder? checkinstall greift bei der Erstellung des Pakets auf rpmbuild zurück. Mir ist dieses Phänomen bislang noch kein einziges mal untergekommen, und ich verwende checkinstall sehr oft.

[ ] Du weisst, was "Requires" sind.

Dann lasse ein mit checkinstall erstelltes Paket doch mal von jemandem anderem auf seinem eigenen System installieren, welches z.B. ein benötigtes Paket nicht installiert hat. Typischer Fall wäre, daß das Paket "ohne Fehler" installiert wird aber nicht läuft, weil eine shared library nicht gefunden wird.

Genau das passiert mit einem ordentlich gebauten RPM nicht, denn da werden die fehlenden Pakete zumindest "angemeckert" (rpm) oder bei einem Paketmanager wie z.B. Yast/APT/smart/YUM/rug/zypper/YUM (usw.) auch noch gleich mit aufgelöst.

Und zum Thema Mitlesen .. naja :

Ich hatte checkinstall als "Quick and Dirty" bezeichnet (nachdem ich weitere und bessere Alternativen zuvor genannt hatte) und nie gesagt, daß es ungeeignet wäre.

Es ist aber _KEIN_ vollwertiger Ersatz für den Bau mit rpmbuild sondern etwas, was man verwenden kann, wenn es schnell gehen soll.

Aber das wurde Dir ja schonmal gesagt:

http://www.unixboard.de/vb3/showthread.php?t=27189&page=2

Ich verwende checkinstall immer mal wieder zum Testen.

Es ist sicherlich besser als alles mit make install ins System zu prügeln aber das wars dann auch schon.

BTW:

Versuche mal ndiswrapper mit checkinstall als User zu bauen.

Greetz,

RM

[gropiuskalle]

*grunz*


Interessant, daß Du das als User ohne den absoluten Pfad aufrufen kannst. Normalerweise ist für einen normalen User /usr/sbin nicht in $PATH oder ist das ein Ubuntu? (das aber nur am Rande)

Nein, das ist SuSE, und das kannst Du ebenfalls - dies ist keine unübliche Art, checkinstall zu verwenden.


Dann lasse ein mit checkinstall erstelltes Paket doch mal von jemandem anderem auf seinem eigenen System installieren, welches z.B. ein benötigtes Paket nicht installiert hat. Typischer Fall wäre, daß das Paket "ohne Fehler" installiert wird aber nicht läuft, weil eine shared library nicht gefunden wird.

Das stimmt allerdings - solange die benötigten dependencies auf dem System vorhanden sind, meldet ein Paketmanager bei einem so erstellten .rpm lediglich eine Warnung in der Art von 'user kalle does not exist, change permission to root' oder so (wohlgemerkt: auf einen fremden System). Schon das ist für sich eigentlich unsauber, auch wenn daraus keine Probleme entstehen (auf kde-apps.org hocken manchmal solche Pakete rum, aber es stimmt schon, sowas eignet sich nicht zum Verteilen). Problematisch wird's auf jeden Fall, wenn benötigte Pakete fehlen, aber ich bau ja auch keine Pakete für den offiziellen openSUSE-build-service, sondern für mich selber, daneben installiere ich solche .rpms allerhöchstens noch auf Systemen, die ich sehr gut kenne. checkinstall zielt darauf ab, zum einen ein 'make install' zu vermeiden, und zum anderen einen Kompiliervorgang nicht ständig wiederholen zu müssen, wenn man z.B. mit unterschiedlichen compileroptionen erstellte .rpms nacheinander testen möchte (nur mal so als Beispiel). Das ist kein Nachteil, sondern einfach eine etwas andere Intention, welche checkinstall nicht weniger zuverlässig als Paketbauer macht als rpmbuild. Gut, Du stellst ja checkinstall nicht per se als schlechte Anwendung dar, aber gerade weil ich es so häufig benutze, wüsste ich, warum ein ja wohl sehr erfahrener Anwender wie Du es als (im Umkehrschluss) schlechtere Alternative dastellt. Kommt es also nicht darauf an, wofür man es verwendet? Ich meinerseits kritisiere ja rpmbuild nicht (warum auch).


Aber das wurde Dir ja schonmal gesagt:

http://www.unixboard.de/vb3/showthre...t=27189&page=2

Öhm, was hat dieser ub-thread mit dem Thema hier zu tun? In der Diskussion zwischen Bâshgob und mir ging es darum, ob es sinnvoller ist, checkinstall als user zu verwenden (bzw. ob dies überhaupt möglich ist), um das .rpm anschließend gesondert zu installieren (meine Variante), oder als root, um sich den extra-Arbeitsschritt zu ersparen. Das Fazit von Bâshgob lautete:


Einstellungssache.

Dass er grundsätzlich SlackBuild bevorzugt, liegt daran, dass er ein Slackware-System fährt - er hat mir also durchaus nicht 'schonmal gesagt', dass checkinstall der schlechtere Paketbauer wäre.


Versuche mal ndiswrapper mit checkinstall als User zu bauen.

Dann baut man das halt als root. Jeder so, wie es ihm gefällt bzw. was eben möglich ist.

[Rain_maker]

Dann versuchs doch mal als root, wenn es als User nicht geht.

Greetz

RM

[gropiuskalle]

Offenbar willst Du auf irgendwas bestimmtes hinaus, aber es ist Freitag Nacht, und ich fange jetzt bestimmt nicht an, irgendwelche Pakete zu übersetzen, die ich garnicht benötige, nur damit ich irgendeine Haarspalterei von Dir kapiere. Eine einzelne aus irgendeinem Grunde nicht mit checkinstall baubare Anwendung spricht doch nicht gegen checkinstall als solches. Ich habe damit schon etliche Pakete völlig ohne Probleme bauen können. Wo soll denn *auf dieser Ebene* irgendein Nachteil gegenüber rpmbuild bestehen? Zumal checkinstall doch rpmbuild benutzt.

[Rain_maker]

Die Nachteile stehen schon alle da und das ist beileibe keine Haarspalterei.

Ich will es Dir aber mal gerne erklären.

Wenn man häufger in Foren versucht Usern zu helfen, die z.B. nur ein winziges Modul brauchen, damit z.B. ihre WLAN-Karte läuft, dann hat man irgendwann mal die Idee, man könnte doch nette, kleine RPMs bauen, die man dann zum Download anbietet und den Usern das Selbstkompilieren erspart.

Idee => Nehmen wir doch checkinstall.

Tja und dann läuft man damit regelmässig gegen die Wand, z.B. lässt sich ein Paket weder als User noch als root bauen (ndiswrapper 1.45 wäre so ein Beispiel) oder aber (und das ist noch viel besser) man kann es als root "bauen", aber das RPM ist leer (ich weiß leider nicht mehr, bei welchem Paket das war).

Nächstes Problem wäre (wenn es denn funktionieren würde), daß man für jede Kernelversion und für jedes Kernelflavor die Pakete einmal bauen müsste und dazu teilweise auch noch jeden Kernel booten müsste, da viele Pakete bei Make "uname -r" auslesen.

Willst Du Dir 5 verschiedenene Kernel installieren und am besten dann noch 2 Systeme einmal 32 und einmal 64 Bit?

Mal davon abgesehen, daß ich keinen 64-Bit fähigen Rechner habe.

Die Probleme mit den Abhängigkeiten sind da noch nicht dabei, wie gesagt, ein gutes RPM muß auf jedem System installierbar sein, daß es hinterher auch läuft und ggf. Abhängigkeiten installiert oder zumindest angemeckert werden.

Und aus einem src.rpm kann es z.B. jemand mit großer Wahrscheinlichkeit auf einer anderen Version bauen, sofern die Unterschiede nicht zu groß sind bzw. einige kleine Änderungen am SPECfile gemacht werden.

SuSE bietet außerdem bei Kernelmodulen seit 10.1 sogenannte "kmp"-Pakete an, welche so gebastelt sind, daß sie ein Kernelupdate "überleben", man muß also nicht sofort nach einem Kernelupdate alle Pakete neu bauen.

Und dazu habe ich mir einfach nur die SPECs aus dem entsprechenden src.rpm angesehen und auf "meine" kmp-Pakete "umgestrickt", die Änderungen sind meist marginal und sehr logisch nachzuvollziehen.

Noch bin ich relativer Anfänger, aber innerhalb kürzester Zeit sind da eine Menge sehr nützlicher und recht häufig heruntergeladener Pakete draus geworden.

Für den "Hausgebrauch" kann einem checkinstall vieles erleichtern, aber es ist eben recht unflexibel und kann eben nur "Hausmannskost" zubereiten. Alles, was vom normalen Dreisatz auch nur ein wenig abweicht, wird mit großer Wahrscheinlichkeit Probleme machen.

Und rpmbuild ist speziell für SuSE-Pakete nicht mal mehr das absolut beste Mitte der Wahl, da gibt es wohl sogar Buildscripte des Buildservice, die sich wohl noch besser um Abhängigkeiten usw. kümmern sollen.

Wenn ich den Thread finde (war IIRC im LC), dann poste ich den noch.

Greetz,

RM

[gropiuskalle]

Okay, bevor es sich zuspitzt (ich glaube an Flames ist keiner von uns beiden interessiert), einigen wir uns darauf, das checkinstall nicht geeignet ist, um .rpms jenseits des eigenen Systems zu backen, und ich stimme Dir deshalb zu, dass solchermaßen erstellte Pakete besser nicht verteilt werden sollten (das schrieb ich allerdings auch bereits). Bezüglich der Kernelversionen muss ich Dir jedoch wiedersprechen: ich habe allein auf meiner SuSE schon 3 verschiedene Kernel (2.6.18.8-0.3 - default | 2.6.19-5-rt - realtime | 2.6.22-rc6-git1-15 - vanilla, also völlig unterschiedliche Varianten), und da gab es wirklich nie Probleme mit den selbst kompilierten Sachen, weder bei kleineren Proggies noch bei den umfangreicheren. Auch die anderen von Dir geschilderten Probleme sind mir bislang halt noch nicht untergekommen - das kommt im Einzelfall vielleicht auf die jeweilige Anwendung an, aber sobald ein ./configure und make bei mir sauber durchlaufen, funktioniert das checkinstallen anstandslos. Ich habe sogar selbst kompilierte Pakete bei einem upgrade von 10.1 auf 10.2 locker 'mitnehmen' können.


Alles, was vom normalen Dreisatz auch nur ein wenig abweicht, wird mit großer Wahrscheinlichkeit Probleme machen.

Hm, aber die entscheidenden Optionen werden doch beim ./configure mitgegeben und geprüft. checkinstall ist durchaus in der Lage, .rpms zu erstellen, die mit meterlangen ./configure-Kommandos zusammengepuzzelt werden. Das ist wirklich kein Problem (ansonsten man sich das Übersetzen ja zumindest unter SuSE sparen könnte, denn deren Repositories haben ja praktisch keine Lücken). Vielleicht leitest Du Deine Eindrücke ein wenig zu sehr von Deinen schlechten Erfahrungen ab - diese sind aber ziemlich konträr zu meinen, und ich baue fast täglich irgendwelche Pakete.

Und was ich nicht so ganz verstehe, ist der Umstand, dass Du mein Argument ignorierst, dass checkinstall doch auf rpmbuild aufsetzt (und dessen Optionen zur Verfügung stellt, schau Dir mal an, was die checkinstallrc an Möglichkeiten bietet).

Edit: Glückwunsch zum 3000. lf.de-Beitrag! :)

[Rain_maker]

Weil der beste Bauarbeiter (rpmbuild) nichts nutzt, wenn der Architekt (checkinstall) nur kleine Häuschen zeichnen kann.
Immerhin kann rpmbuild doch schon einiges an Abhängigkeiten (glücklicherweise) automatisch erkennen, sonst könnte man checkinstall nämlich ganz vergessen.

Logischerweise gibt man übrigens im selbsterstellten SPECfile die ./configure Optionen auch mit (und eben bei Bedarf noch vieles mehr).

So kann man z.B. Pakete aufsplitten (extra devel oder debuginfo bzw. ein kmp-Paket und ein Paket mit config-Dateien), man kann weitere Quellen (wie z.B. eine nicht im Originalpaket enthaltene Dokumentation) einfügen, Patches hinzufügen/entfernen ohne sie alle von Hand der Reihe nach anwenden zu müssen.

Und last but not least einen ordentlichen Changelog erstellen, der auch die Veränderungen gegenüber den letzten Versionen ordentlich dokumentiert.

Das geht alles mit Checkinstall _nicht_ oder ist zumindest deutlich umständlicher, wenn man mal eine neue Version bauen will.

Ich schreibs nochmal, checkinstall ist eine Notlösung, die "Quick and Dirty" ist, nicht mehr aber auch nicht weniger.

Ach ja, danke für den Hinweis auf checkinstallrc hier mal eine Default-Einstellung (openSUSE 10.2, checkinstall-1.6.0-34)



# RPM optional flags
RPM_FLAGS=" --force --nodeps --replacepkgs "

Muß man sowas kommentieren? OK, ich machs mal => *AUTSCH*

Na glücklicherweise ist das auch Default:



# Install the package or just create it?
INSTALL=0Schwein gehabt.

Greetz,

RM

Nachtrag: Thx, ist mir ehrlicherweise gar nicht aufgefallen, naja nun sinds schon 3002

[gropiuskalle]

Weil der beste Bauarbeiter (rpmbuild) nichts nutzt, wenn der Architekt (checkinstall) nur kleine Häuschen zeichnen kann.

Der Architekt ist aber doch ./configure... Ach was soll's, ich glaube, alles gegeneinander rennen hilft nichts, wenn man einfach (wie es mir ziemlich offensichtlich scheint) völlig andere Ansprüche an einen Paketbauer stellt. Ich möchte weder .src.rpms bauen noch vom Notar signierte Pakete für den build-service erstellen erstellen, deswegen will ich dieser Argumentationskette nicht mehr folgen (dieses Recht nimmst Du Dir ja auch, indem Du zwei Drittel meines Geschreibsels ignorierst), außerdem ging es in diesem thread überhaupt nicht um diese Ebenen, und schon garnicht um das Erstellen von zusätzlichen devel und / oder debugs. Bringt doch nix, das Thema immer mehr zu erweitern (erst Recht, wenn es sich um Ebenen handelt, von denen ich *hust* leider wenig Ahnung habe). Ich spreche nur aus Erfahrung, und Du wusstest (sei mal ehrlich) bis gestern noch nicht mal, dass man checkinstall auch als user verwenden kann.

Wie gesagt, was soll's. Auf die nächsten 3000!

[BedriddenTech]

Das größte Problem bei Checkinstall ist doch, daß Dateien, die von statisch gelinkten oder setuid-/setgid-Programmen erstellt wurden, aufgrund des verwendeten LD_PRELOAD-Mechanismus garnicht erst erkannt werden.

[Rain_maker]

... und Du wusstest (sei mal ehrlich) bis gestern noch nicht mal, dass man checkinstall auch als user verwenden kann.

Jepp, dieses Feature ist sogar so geheim, daß nicht mal die Dokumentation des Programms davon weiß?!

http://asic-linux.com.mx/~izto/checkinstall/docs/README


== 2.6 == Package creation

o You normally would su and make install. Now it's only su:

su
password: xxxxx

o Run checkinstall:

checkinstall

NOTE: If you give no arguments to checkinstall it will run a "make install".
If you give arguments, the first non-option argument will be used as the
install command. This is useful when the install command is not "make install"
but something else like "make install_packages" or "setup" or whatever, i.e.

checkinstall make install_packages
checkinstall make modules_install
checkinstall install.sh
checkinstall setup
checkinstall rpm -i my-package-1.0.i386-1.rpm

Irgendwie strange.

Greetz,

RM

[drcux]

@RainMaker:


%define name rt61-rt73-legacy-firmware
%define version 1.0
%define release 1
...
Name: %{name}
Version: %{version}
Release: %{release}

Doppelt gemoppelt, die defines kannst du getrost weglassen:

"Name: blahblupp" macht das gleiche wie "%define name blahblupp".

Hier mal mein dummy-rpm womit ich/wir testen:


# norootforbuild

Name: dummy
Summary: dummy
License: GPL
Group: dummy
Version: 1.0
Release: 0.pm.3
URL: www.dummy.test
Source0: dummy.tar.gz

Packager: Detlef Reichelt <detlef@links2linux.de>

BuildRoot: %{_tmppath}/%{name}-%{version}-build

%description
dummy

%description -l de
dummy-de

%prep
%setup -q -n %{name}
%build
%install

%__install -dm 755 %{buildroot}/tmp
%__install -m 755 dummy.txt %{buildroot}/tmp/dummy.txt

%clean
[ -d %{buildroot} -a "%{buildroot}" != "" ] && %__rm -rf %{buildroot}

%files
%defattr(-, root, root)
/tmp/dummy.txt

%changelog
* Wed Oct 18 2006 Detlef Reichelt
- dummy 1.0

Im dummy.tar.gz ist nur eine Datei (dummy.txt) die nach /tmp installiert wird.

[Rain_maker]

Hey!

Vielen Dank drcux.

Wie gesagt, noch ziemlicher Anfänger bzgl. Paketbau, da kann ich solche Hilfe gebrauchen (das mit den Defines hatte ich auch irgendwann mal als "seltsam, wieso steht das denn zweimal da?") bemerkt.

OK, ich muß zugeben, daß ich das SPEC aus einem etwas älteren "umgeschrieben" hatte.

Ich lese mir gerade auch die SUSE Package Conventions (http://developer.novell.com/wiki/index.php/SUSE_Package_Conventions) durch und merke, daß ich noch verdammt viel zu Lernen habe.

Aber => rpm basteln macht echt Laune :)

Greetz,

RM

[drcux]

Aber => rpm basteln macht echt Laune :)


jepp, und wenn man das Grundprinzip des SPEC-Files begriffen hat, ist es auch nicht wirklich schwierig (wenn denn die Sourcen ordentlich sind) ;) .

[BedriddenTech]

drcux, darf ich dein RPM mal kommentieren bzw. fragen, warum du gewisse Dinge tust?

Sind "%__install", "%__rm" & Co nicht deprecated?
AFAIK sollte der Packager in der ~/.rpmmacros stehen, nicht im Spec selbst.
Dein %clean ist ziemlich gefährlich. "rpmbuild --buildroot=/ tut nämlich weh. ;) Wie wärs stattdessen mit

[ "$RPM_BUILD_ROOT" -a -d "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" =! '/'] && rm -rf "$RPM_BUILD_ROOT"

Mal was ganz anderes: Ich hatte, als ich vor ein paar Monaten einstieg, ziemliche Probleme, anständige Dokumentation zu finden. wraptastic.org ist ziemlich versteckt. Und davon abgesehen gibt es eine ganze Menge verschiedener RPM-Versionen (4.4.2 wird auf rpm.org gewartet und aufgemöbelt, der Entwickler von RPM ist allerdings schon bei 5.0 oder 5.0.1 angelangt) - welche Version nutzt ihr?

[drcux]

drcux, darf ich dein RPM mal kommentieren bzw. fragen, warum du gewisse Dinge tust?




Sind "%__install", "%__rm" & Co nicht deprecated?


Hm, sind sie? Mir es nicht bekannt und warum sollten so einfache Macros "deprecated" sein?



AFAIK sollte der Packager in der ~/.rpmmacros stehen, nicht im Spec selbst.


Ja, normalerweise schon, nicht aber, wenn du ein Build System mit mehreren Leuten benutzt, dort gibt es nicht unbedingt ein ~/.rpmmacros.



Dein %clean ist ziemlich gefährlich. "rpmbuild --buildroot=/ tut nämlich weh. ;)


Wer als Root baut, hat eh selber schuld. ;)


Wie wärs stattdessen mit

[ "$RPM_BUILD_ROOT" -a -d "$RPM_BUILD_ROOT" -a "$RPM_BUILD_ROOT" =! '/'] && rm -rf "$RPM_BUILD_ROOT"


Und wenn $RPM_BUILD_ROOT = "/*" oder "/.*" oder "/usr" oder ...



Mal was ganz anderes: Ich hatte, als ich vor ein paar Monaten einstieg, ziemliche Probleme, anständige Dokumentation zu finden. wraptastic.org ist ziemlich versteckt. Und davon abgesehen gibt es eine ganze Menge verschiedener RPM-Versionen (4.4.2 wird auf rpm.org gewartet und aufgemöbelt, der Entwickler von RPM ist allerdings schon bei 5.0 oder 5.0.1 angelangt) - welche Version nutzt ihr?

Bei SUSE ist es die 4.4.2

[BedriddenTech]

Hm, sind sie? Mir es nicht bekannt und warum sollten so einfache Macros "deprecated" sein?

Das solltest du den Entwickler von RPM fragen. :) In meiner /usr/lib/rpm/macros steht bei einigen dieser einfachen Macros der Hinweis, der Eintrag sei nur noch zu Kompatibilitätszwecken vorhanden.


Ja, normalerweise schon, nicht aber, wenn du ein Build System mit mehreren Leuten benutzt, dort gibt es nicht unbedingt ein ~/.rpmmacros.

Das mußt du mir erklären - ich dachte, gerade wenn mehrere Leute Specs schreiben und ein Build System nutzen, braucht jeder seine eigene Version der rpmmacros...?


Wer als Root baut, hat eh selber schuld. ;)
(...)
Und wenn $RPM_BUILD_ROOT = "/*" oder "/.*" oder "/usr" oder ...

Natürlich kannst du diese einfach Abfrage irgendwie umgehen. Sie ist auch nicht dafür da, böswillige Personen davon abzuhalten, Pakete als root zu bauen und dann das System zu töten. Sie ist dafür da, dappische Personen davon abzuhalten, "--clean --buildroot=/" zu nutzen um "nur mal schnell ein Paket zu installieren", wie das öfter mal getan wird. Wobei ich den Gedankengang auch nicht ganz nachvollziehen kann... ;)


Bei SUSE ist es die 4.4.2

Hm, vielleicht sollte ich mir mal die diversen RPM-Pakete anderer Distributionen ansehen. Da ich meine eigene baue, kann ich schlecht auf die zurückgreifen, die mir jemand liefert, aber Anregungen darf man sich ja holen. :) Leider ist es ein schierer Krampf, RPM (richtig) aus den Quellen zu übersetzen, und noch schlimmer sieht der RPM-Quelltext aus. *schauder*

[drcux]

Das solltest du den Entwickler von RPM fragen. :) In meiner /usr/lib/rpm/macros steht bei einigen dieser einfachen Macros der Hinweis, der Eintrag sei nur noch zu Kompatibilitätszwecken vorhanden.


In meiner nicht, was wird denn ansonsten vorgeschlagen?



Das mußt du mir erklären - ich dachte, gerade wenn mehrere Leute Specs schreiben und ein Build System nutzen, braucht jeder seine eigene Version der rpmmacros...?


Warum? Das einzige was sich bei den einzelnen Usern im Spec unterscheiden "darf" ist der Packager. Nur dafür jedem seine eigenen Macros in ein Build System zu basteln ist schon recht aufwändig.




Natürlich kannst du diese einfach Abfrage irgendwie umgehen. Sie ist auch nicht dafür da, böswillige Personen davon abzuhalten, Pakete als root zu bauen und dann das System zu töten. Sie ist dafür da, dappische Personen davon abzuhalten, "--clean --buildroot=/" zu nutzen um "nur mal schnell ein Paket zu installieren", wie das öfter mal getan wird. Wobei ich den Gedankengang auch nicht ganz nachvollziehen kann... ;)


Lernen durch Schmerzen. ;)

[BedriddenTech]

In meiner nicht, was wird denn ansonsten vorgeschlagen?

Die Befehle direkt schreiben, sprich "rm" statt "%__rm". Ich weiß nicht, warum, wie gesagt, ich habe nur die Kommentare gelesen. Ich nutze übrigens RPM Version 4.4.6.



Warum? Das einzige was sich bei den einzelnen Usern im Spec unterscheiden "darf" ist der Packager. Nur dafür jedem seine eigenen Macros in ein Build System zu basteln ist schon recht aufwändig.

Eben nicht: Eine Specdatei ist einzigartig. Sie mag zwar im RCS sein und deswegen in vielen Arbeitskopien vertreten, aber wenn du sie eincheckst, änderstest du jedes Mal den Packager mit. Das kann doch nicht effektiv sein, oder? Wenn du im Buildsystem in deinem Heimatverzeichnis eine eigene Datei ".rpmmacros" liegen hast, und dort der Packager eingetragen ist, dann wird der beim Bauen automatisch eingesetzt, ohne, daß am Specfile irgendwas geändert werden soll. Dasselbe gilt übrigens auf für GnuPG-Signaturen, die gehören eigentlich auch nicht ins Spec.

[drcux]

Die Befehle direkt schreiben, sprich "rm" statt "%__rm". Ich weiß nicht, warum, wie gesagt, ich habe nur die Kommentare gelesen. Ich nutze übrigens RPM Version 4.4.6.


naja, wenns denn so sein soll, ich find die kleinen Macros fein, braucht man sich nicht um die Pfade/Befehle kümmern. Wurde halt bis jetzt vom RPM-Packager (angepasstes /usr/lib/rpm/macros) vorher richtig gesetzt...



Eben nicht: Eine Specdatei ist einzigartig. Sie mag zwar im RCS sein und deswegen in vielen Arbeitskopien vertreten, aber wenn du sie eincheckst, änderstest du jedes Mal den Packager mit. Das kann doch nicht effektiv sein, oder? Wenn du im Buildsystem in deinem Heimatverzeichnis eine eigene Datei ".rpmmacros" liegen hast, und dort der Packager eingetragen ist, dann wird der beim Bauen automatisch eingesetzt, ohne, daß am Specfile irgendwas geändert werden soll. Dasselbe gilt übrigens auf für GnuPG-Signaturen, die gehören eigentlich auch nicht ins Spec.

OK, du hast dich also gerade freiwillig gemeldet, mir bei dem Erstellen des PackMan Build Service zu helfen. Ich schreibs übrigens in Python.... :D

[BedriddenTech]

Uh, mit Python kenne ich mich leider kaum aus. Ich wollte ein ähnliches System in Perl mal schreiben, aber ich wollte schon so viel. Wenn man sich eine eigene Distribution abseits von LFS, Gentoo & Co aufbaut, hat man einiges zu tun. Aber ich helfe gerne. :D Gibt's schon einen SF.net-Account o.ä.?

[drcux]

Gibt's schon einen SF.net-Account o.ä.?

Nein, nur PackMan intern. Ich "bastel" eigentlich im Moment nur Teilprogramme...

Zeit ist das, was einem am meisten fehlt.... :(