[linux-l] rpm's bauen

[Volker Grabsch]

On Thu, Feb 15, 2007 at 01:49:19PM +0100, Olaf Radicke wrote:
> > > Ich bräuchte ein rpm was die DB vorbereitet
> >
> > Das würde ich lieber nicht das Paket machen lassen. Lieber das
> > Programm beim ersten Start den Kram anlegen lassen.
> 
> Ich dachte an die Gruppe User, die noch nie eine DB angefasst haben und 
> nur mal schnell gucken wollen, ob das Tool ihre Erwartung erfüllt.

An genau die Leute denke ich auch. Deshalb lieber kein zweites RPM-Paket.

> Der DB-Guru setzt die DB mit geschlossenen Augen, einhändig, in 5 Min. auf.

ACK. Die GUI muss also beide Bedürfnisse befriedigen. Das ist auch nicht
schwer, da kann man sich von den gängigen "Installern" der Web-Applikationen
was abschauen.

> > Deine Applikation könnte beim ersten Start den DB-Namen, DB-User
> > und falls nötig das DB-Passwort erfragen, die Daten (evtl. ohne
> > Passwort) in eine Konfigurationsdatei schreiben (~/.myapp), und
> > fertig.
> 
> Es gibt eine komfortable GUI-Maske, im Klient. Das ist wirklich kein 
> Problem.

Okay, super. Nur, um Missverständnissen vorzubeugen, schlage ich
folgendes vor (vielleicht machst du das ja schon so):

Zwei Möglichkeiten der DB-Einrichtung:

* Neue Datenbank anlegen:
    Pflicht-Eingabefeld: DB-Root-Passwort
    Eventuell noch: DB-Name, DB-User, Tabellen-Prefix
    -> legt neue DB an
    -> legt neuen DB-User an
    -> legt Tabellen an

* Vorhandene Datenbank nutzen:
    Pflicht-Eingabefelder: DB-Name, DB-User
    Eventuell noch: Tabellen-Prefix
    -> legt nur die Tabellen an

Der Neuling gibt beim ersten Start sein DB-Root-Passwort ein,
und gut ist's. Komfortabler geht's kaum. Ein extra RPM-Paket
brauchst du dafür jedenfalls nicht.

> > > und eins was den Klienten installiert.
> >
> > Das ist einfach, solange es keine Web-Applikation sondern eine
> > klassische GUI-App ist. Ich kann dir gern mal eines bauen.
> 
> ...Prima!

Okay, dann noch schnell ein paar Formalitäten, da du recht neu
in Sachen RPM/Debian-Pakete zu sein scheinst:

Ausgangspunkt sind die "pristine sources" AKA "upstream sources".
Also dein Source-TGZ. Das ist unsere gemeinsame Schnittstelle.

Ich sehe, du bietest nur ein Source-ZIP an:
    http://belnet.dl.sourceforge.net/sourceforge/artikel23/artikel23-src-0.2.2.zip
Na gut, dürfte auch gehen.

Was aber sehr viel unangenehmer ist: Dein make.sh ist in seiner
derzeitigen Form völlig unbrauchbar. Man muss es ändern, um überhaupt
bauen zu können. Zudem startet es die Applikation plötzlich. Und
dein src-Verzeichnis ist abhängig von "../doku/artikel_23_doc.xml" ...
WTF? Das hast du bei "artikel23-src-0.2.2.zip" nicht mitgeliefert!
Mir scheint, du hast nicht den Sinn und Zweck von separaten doc-
Paketen begriffen: Sie enthalten nicht die *ganze* Doku, sondern
den *optionalen* Teil der Doku.

Das Ziel von RPM- und Debian-Paketen ist es nicht nur, ein Dateiformat
für Binärpakete mit Konfigurationsdateien etc. zu liefern. Nein, es
geht außerdem darum, einen reproduzierbaren Build-Mechanismus zu haben.

Die Probleme liegen z.T. in deinem Shell-Script (du hast absolute
Pfade zum Compiler eingetragen) und z.T. darin, dass es ein Shell-Script
und kein Makefile ist (im Makefile kannst du Variablen verwenden, und
deren Wert *von außen*, per Kommandozeilenparameter, ändern).

Eine leichte Abhilfe wäre, wenn du statt
    /opt/mono-1.2.2.1/bin/gmcs \
einfach
    gmcs \
schreibst, und bei dir zu Hause das Verzeichnis "/opt/mono-1.2.2.1/bin"
mit in $PATH aufnimmst.

Außerdem solltest du den Startcode rauswerfen. Was hältst du von einem
ordentlichen Makefile, bei dem man mit

    make

compilieret und mit

    make run

das Programm startet (und ggf. vorher compiliert)?

> > Auch die Pfade 
> > ist nicht überall identisch (leider). 
> 
> Ich hab das Zeug bisher immer unterhalb von /opt ab gekippt. Ab besten 
> du guckst die das Bash-Skript an:
> 
> https://artikel23.svn.sourceforge.net/svnroot/artikel23/trunk/src/install.sh

Ja, das ist sehr nützlich.

Und dass es in /opt schreibt, ist genau richtig. Das RPM-Paket wird
allerdings nicht nach /opt installieren, ist ja klar. :-)

BTW, hat es irgendeinen bestimmten Grund, warum du in deinen
Shell-Scripten install.sh und make.sh jeden Befehl mit einem ";"
beendest?

> > Auch praktisch sind da SRC-RPMs, die man mit einem Befehl
> > selbstständig auf seiner Kiste compilieren kann. Am Ende wird ein
> > Binary-RPM ausgespuckt.
> 
> Kann ich nicht einschätzen, ob das ein User u.U. schon überfordert. Ich 
> glaube kitzlig ist, herauszufinden welches der Pfad zur Runtime ist, 
> bzw. wenn es mehere gibt, welche die richtige ist.

Der Normal-User wird nur *eine* Runtime haben, oder?

Und die Auswahl der Runtime kannst du doch selbst über $PATH regeln,
wozu also überhaupt Aufwand darein stecken?

BTW, zu deinem Start-Shellscript:
    cd ;
    mono /opt/artikel_23/artikel_23.exe;

Das ist in keiner Weise portabel.

1. Wieso wechselst du in das Homeverzeichnis des Users?
   (kann das dein Programm nicht selbst rauskriegen?)

2. Was soll der absolute Pfad? Trag doch bei dir zu Hause
   /opt/artikel_23 mit in $PATH ein, dazu ist es schließlich da.

> Ich nehme alles, was mir brauchbar scheint. Ich gehe davon aus, das gute 
> Chancen bestehen, ein RPM für alle zu bauen.

Ja, sieht ganz danach aus.

> SELinux-Policen könnten  vielleicht noch ein Problem werden.

In Sachen SELinux kann ich dir nicht helfen, sorry.


Zusammenfassend:
Ich würde dir gern ein RPM bauen, hätte ich heute auch getan! Aber
dazu musst du deine Sources und Pakete erstmal aufräumen.
Oder mir Zugang zum SVN geben, damit ich das selbst machen kann.

Die "übliche" Lösung wäre, dass das RPM-Paket vorerst selbst
entsprechende Workarounds betreibt, aber das sind mir in diesem
Fall einfach zu viele. Sorry. :-(


Viele Grüße,

    Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR