[linux-l] rpm's bauen
Volker Grabsch
vog at notjusthosting.com
Do Feb 22 22:19:08 CET 2007
On Thu, Feb 22, 2007 at 02:40:25PM +0100, Olaf Radicke wrote:
> Am Mittwoch, 21. Februar 2007 schrieb Volker Grabsch:
> > Was einfaches tut's doch auch. Siehe z.B. ein uraltes SF-Projekt von
> > mir:
> >
> > http://voji.sourceforge.net/
>
> ...Hatte ich mich noch nicht mit beschäftigt.
Sollst du auch gar nicht. Nur einen Blick auf die Seite werfen ...
eine minimale index.html, die zu den wichtigsten Sachen linkt
(Download, Doku, SF-Projekt-Seite).
Ich habe die geschrieben, weil ich die Standard-Projektseite bei
SF einfach zu überladen und zu unübersichtlich finde. Für Entwickler
ist die gut, daher auch ein Link dorthin. Aber für "Besucher", die
das Programm ausprobieren wollen, wollte ich ne "einfache Webseite"
haben ... gut, die ist nicht so schick, aber klein und übersichtlich.
> > Natürlich muss die wichtigste Doku (README, INSTALL) im Source direkt
> > lesbar sein. Aber der Rest (Benutzerhandbuch, etc., also alles was
> > man nicht zum bauen der Binaries braucht) liegt im Source-Paket
> > erstmal nur als "Quelle" vorliegen.
>
> ... Im Unterverzeichnis /src/doku/ richtig?
Klassischerweise src/doc. Aber im Prinzip: ja.
Ebenfalls üblich ist es, das Source-Verzeichnis in Unterverzeichnisse
src/ und doc/ aufzuteilen, und *über* diesen beiden Verzeichnissen
befinden sich dann Makefile, README & Co.
In deinem konkretes Projekt wäre das aber eher verwirrend. Musst du
wissen.
> > > Die Npgsql.dll's sind 'nur' unter Windows ein Krampf. Unter Linux
> > > sind die richtigen Standard mäßig im Mono-Paket drinnen.
> >
> > Nich ganz. Unter Debian musste ich sie als extra Paket installieren.
> > War aber sehr leicht zu finden, und außerdem hätte ich ja auch gleich
> > alle Mono-Pakete installieren können, nicht nur die nötigsten. :-)
>
> ...Ich bin still schweigend davon ausgegangen, das der Mono-Installer
> verwendet wurde.
Wozu, wenn's schon fertig in der Distribution dabei ist? :-)
> > Es wäre schön, wenn die Mono-User einfach Source-RPMs bekämen, die
> > sie dann nicht mit "./configure && make", sondern mit "rpmbuild
> > --rebuild" bauen. Kein Ärger mit configure-Parametern, und heraus
> > kommt ein RPM- Paket, das man sauber installieren und deinstallieren
> > kann.
>
> Ja, aber mit Abhängigkeit zu einer (bestimmten) Runtime-Umgebung?
Wenn die RPM-Paket irgendeinen Sinn ergeben sollen, dann nur auf
Systemen, in denen auch Mono als RPM-Paket vorliegt, am besten also
Teil der Distribution ist.
Und genau von diesem vorhandenen RPM-Paket wäre das artikel_32-RPM
dann "abhängig", d.h. es würde dieses Paket in seinen Dependencies
aufführen und eben verwenden.
Da das aber darauf hinauslaufen wird, dass man einfach nur "mono ..."
aufruft, wäre das Paket genaugenommen lediglich auf die Runtime-
Umgebung festgelegt sein, die zuerst im $PATH steht.
Da ist auch immer die Frage, was man will. Willst du es dem User
möglichst einfach machen, sollte er das RPM-Paket installieren und
nutzen können, ohne etwas von Mono zu wissen.
(z.B. unter RedHat: "yum install artikel23" ... und es lädt automatisch
die Mono-Paket mit herunter und installiert sie, falls der User noch
kein Mono installiert hat.)
Ein RPM-Paket, das total flexibel auf jede beliebige Mono-Installation
reagiert, wäre ein Widerspruch in sich. Für sowas gibt es Binary-
ZIP-Files (bzw. Binary-TGZ). Die entpackt man sich irgendwohin,
(nach $HOME oder nach /opt), passt irgendwelche Pfade an, und startet
es direkt. Für diese Zielgruppe der Mono-Selbst-Installierer sind
RPM-Pakete einfach nicht das richtige "Medium".
Die Zielstellungen von Binary-ZIPs und RPM/Deb-Paketen gehen etwas
auseinander. Die sollte man IMHO sauber trennen, statt irgendein
Mittelding zu erzeugen.
> > Fallback. Erst im aktuellen Verzeichnis suchen. Liegt dort keine
> > Konfiguration, pack sie ins APPDATA.
>
> Was ist, wenn das Programm das erste mal aufgerufen wird? Dann gibt es
> nämlich auch noch kein config-file. Ich weiß nicht, ob es für den
> Benutzer so transparent ist, nach welcher Reihenfolge das Prog die
> Verzeichnisse abgrast.
>
> Also die Regel soll lauten:
>
> Gibt es eine Config im aktuellen Verzeichnis?
> Wenn ja, benutze sie - ende.
> Wenn nein, suche im /home/user/. weiter.
> Wenn gefunden, benutze sie - ende.
> Wenn nicht, lege neue an...
>
> ...So?
Jain ... viel besser fände ich es, wenn artikel23 seine Config-Files
erst gar nicht im eigenen Verzeichnis anlegt, sondern *immer* unter
/home/user/.artikel_23 bzw. APPDATA/... entsprechend mit dieser tollen
portablen Funktion, die dir zur Verfügung steht.
Die Sonderregel, dass das Config-File auch im aktuellen Verzeichnis
liegen darf, für wen ist die nützlich? Für normale Windows/Linux-User
jedenfalls nicht. Dort gibt es jeweils Standard-Verzeichnisse für
sowas, die man auch nutzen sollte.
Höchstens bei der Entwicklung wäre solch ein Sonderverhalten sinnvoll,
aber auch hier sehe ich kein Problem damit, dass beim Austesten die
Konfiguration gleich an der "richtigen Stelle" landet, statt im
aktuellen Verzeichnis.
> > > > > Wenn rpm die wo anders abwirft, muss ich halt noch anpassen.
> > > >
> > > > Was genau sind deine System-Dateien?
> > >
> > > Text-Dateien und Icons.
> >
> > Achso. Das ist normalerweise /usr/share/artikel_23/, auch DATADIR
> > genannt. Unter Windows ist es %PROGRAM_FILES%\Artikel_23 ... und ja,
> > wenn im aktuellen Verzeichnis schon was liegt, kann man da ja nehmen,
> > anderenfalls eben die "korrekten" Pfade.
>
> Wollen wir es wirklich so kompliziert machen? Warum nicht alles
> in /opt/artikel23/* abwerfen?
Hat Mono denn dafür keine Funktionen? Für Konfigurations-Dateien gibt's
das doch auch.
Falls nicht, wie wär's dann mit folgendem. Das ist sowohl standard-
konform als auch relativ einfach (hoffe ich):
Das Programm arbeitet wie bisher, und erwartet die "System-Dateien"
(eigentlich heißt das "Daten-Dateien") im selben Verzeichnis wie die
artikel_23.exe
Was aber gut wäre: Wenn es nicht blind das "aktuelle Verzeichnis" nimmt
(das kann ja sonstwo sein), sondern wirklich den Pfad zur eigenen
artikel_23.exe herausfinden könnte. Unter Python heißt das:
os.path.dirname(__file__)
Es wäre z.B. super, wenn du einen chdir() dorthin zum Beginn des
Programmes machen würdest.
Unter Windows läuft es dann wie gehabt. Unter Linux im Binary-ZIP
ebenfalls, das man nun überall hin entpacken kann (z.B. nach
/opt/artikel23).
Im RPM-Paket würde ich den Krempel nach /usr/share/artikel23/
packen, inkl. artikel_23.exe, und dann ein Shell-Script namens
/usr/bin/artikel23 anlegen:
#!/bin/sh
mono /usr/share/artikel23/artikel_23.exe
(auf einen "cd"-Befehl würde ich an der Stelle gern verzichten,
weil das wiegesagt Aufgabe des Programmes ist, und ein cd-Befehl
somit nur der Workaround für einen Bug im Programm wäre.)
> > Hab schon ein ordentliches Makefile beigesteuert und dein
> > make.sh entsprechend angepasst.
>
> Danke. Das Makefile OHNE make.sh scheitert übrigens auf meinen System
> (FedoraCore 6). Die Dist-Runtime ist zu alt. Läuft das unter Debian
> durch?
Ja, dort rennt es ohne Probleme. Ich habe ein Debian/Etch.
Kommt man mit der vorinstallierten Mono-Version nicht aus, braucht
man sowieso ein extra Mono-Paket und hat damit einen Sonder-Pfad,
den man bei make als Parameter (siehe make.sh) einfach angeben kann.
Das Makefile braucht also nicht mehr geändert zu werden. Für den
Standard-Fall arbeitet es korrekt, für den Sonderfall gibt man
einen Parameter an. Will man diesen Parameter automatisieren ...
nunja, dann kann man sich make.sh anpassen oder sich selbst eine
Datei mit diesen 1-Zeiler anlegen.
Ach ja, noch ne Sache: Das Projekt heißt "artikel23", das Repository,
die ZIP-Dateien, etc. ebenfalls. Aber das Binary heißt "artikel_23.exe".
Sollte es nicht lieber in "artikel23.exe" umbenannt werden?
Viele Grüße,
Volker
--
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR
Mehr Informationen über die Mailingliste linux-l