[linux-l] rpm's bauen

[Olaf Radicke]

Am Sonntag, 18. Februar 2007 18:02 schrieb 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.

Der Vergleich ist unfair. Die Web-Applikationen arbeitet über Apache, 
der (in der Regel) ausreichende Rechte für die DB hat (wenn nicht 
gerade SELinux scharf gemacht wurde).

Meine Applikation hat nur die Rechte des Users, der sie ausführt. Und 
ich hoffe der ist nicht "root", nicht "postgres" oder "apache" 
bzw. "httpd".

Ich muss also ein extra Tool machen, das der User mit peviligierten 
Rechten startet. 

> > > 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

Bei mir z.B. hat DB-Root kein Passwort. Ich mache unter root ein su zu 
postgres und lokal unter der Benutzerkennung "postgres" kann ich auf 
die DB ohne Authentifizierung zugreifen. DB-Root kann weder über 
Netzwerk kontakten, noch kann er sich direkt lokal einlogen. Selbst 
root muss ein su machen und kann nicht mit einer userkennung die DB 
kontaktieren.

Jedes Tool das daß nicht weiß, würde hier schon die Segel streichen.

>     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

Ich glaube das einzige Tool was fehlerfrei arbeitet, wäre eines das ein 
Fenster auf poppen lässt in dem steht "Wir freuen uns, das sie unsere 
DB-Anwendung verwenden wollen. Leider ist 
Klassen-Bibliothek 'System.Glaskugel.DBInstall' noch unvollständig. 
Solange fragen sie bitte ihren DB-Guru ihrer Nachbarschaft um Hilfe. - 
Vielen Dank!"

:-)


...Ich glaube wir knicken das. :-( 

> 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.

Bitte immer im Hinterkopf behalten: Zielplatform ist Linux, MacOS UND 
Windows. Zip kennen viele WinUser. Tar....

> 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. 

Glaube ich dir. Ist nur ein "Abfallprodukt" von mir, um mit einen Befehl 
den Code zu testen. Also eigentlich ein Entwickler-Tool von mir.

> Zudem startet es die Applikation plötzlich. Und 
> dein src-Verzeichnis ist abhängig von "../doku/artikel_23_doc.xml"
> ... WTF? 

Ja. Da war/bin ich schluderig. Das make.sh hat im Tag-Zweig eigentlich 
anders aus zu sehen. Da sieht man ihm wieder an, das es ein 
Entwickler-Hilfs-Tool ist und kein wirkliches make.

> 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.

In erster Linie war es "Lieblosigkeit" und "schlampigkeit". Die ODT-Doku 
(bzw. PDF) ist eigentlich die wichtigste, die auch eigentlich immer 
dabei sein sollte. Nur kam mir die Überlegung, das vielleicht Leute 
zunächst nur die Doku sehen wollen, bevor sie sich den Rest ernsthaft 
ansehen. Also hielt ich es für eine gute Idee das getrennt zu machen. 
Ist aber wahrscheinlich unsinnig, weil die meisten User probieren um 
dann fest zu stellen, das sie nicht weiter kommen und DANN erst die 
Doku ansehen.

Bleibt die Frage wo hin mit der ODT/PDF-Doku? In /src/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) 

Ja, weil ich zwei Compiler-Versionen habe.

> 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.

Mit zwei gleichnamigen Compiler wird das so nicht klappen. Es ist auch 
nichts ungewöhnliches unter Mono-Usern mehrere Mono-Installationen zu 
haben. Mono entwickelt sich so rasant schnell, das die Mono-Version der 
Distribution nur für die Distrebutionseigenen Progs benutzt werden.

Deshalb auch die "artikel23.sh". Das kann der User das Verhalten noch 
etwas anpassen an seine lokalen Verhältnisse. Und wenn er eine neue 
Version drüber bügelt, wird die alte "artikel23.sh" nicht gelöscht. 
Also ein workaround. Aber ich klebe nicht an der Lösung.  

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

Ich denke, es ist das was 99% der User erwarten. Ich habe nicht auf das 
sh-Skript verwiesen, weil ich es so unglaublich schön und elegant 
finde, sonder lediglich als Ausgangspunkt. Es ist ein Tool was mir 
bisher die Arbeit erleichtert hat. Wenn es ein richtiges make gibt, 
werde ich es vielleicht um benennen in "test-built.sh" 
oder "test-built.shitt" oder "test-bull.shitt" oder so. 

> und mit
>     make run
>
> das Programm startet (und ggf. vorher compiliert)?

Das ist nicht mal nötigt. Das übliche "make install" wäre noch 
interessant.

> > > 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/i
> >nstall.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?

Nö. War wahrscheinlich nur ein "Reflex".

> > > 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?

Kommt wahrscheinlich darauf an, wie exzessiv er schon dotnet-programme 
benutzt. Ob er die seiner Distribution benutzt oder die vom 
Mono-Projekt und da wiederum, ob er den Mono-Installer benutzt oder die 
rpm's.

Aber um dich zu trösten: Unter Windows hat man zwar (meist) nicht den 
Terz mit der Runtime (meist wird die von Microsoft verwendet) aber 
dafür hast du ganz viel "Spaß" mit der dll-Hölle (in erster Linie die 
dll's von Npgsql).

> 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?)

Es gibt kein /home bei Windows. Das Programm sucht eine Konfigurations 
Datei (die sonst irgendwo sein könnte) im aktuellen Verzeichnis. Das 
hat Vor- und Nach-teile. 

Aber es kommt noch "schlimmer". Das Programm erwartet seine 
system-Dateien (die es für alle User verwendet), in den Pfaden...

  /opt/artikel_23/*
oder
  ./*

Wenn rpm die wo anders abwirft, muss ich halt noch anpassen.

Unter Windows liegt die exe und der Rest immer zusammen. Da reicht der 
Pfade "./*". 

> 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.

Eine .exe ist erstmal nicht ausführbar unter Linux. Man kann Konqueror 
so einstellen, das er alle .exe mit mono startet. Deshalb war die exe 
nicht in $PATH. Wenn du "artikel_23.exe" in der bash startest bekommst 
du (im besten Fall) die Meldung: 

install the Windows version of Mono to run .NET executables

> 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.

Ist Okay. 
Hast du ein sf.net-Account?
Du weist das der sche** SVN-Copy-Befehl bei SF.Net nicht funktioniert?
Sagst du vorher noch an was genau du tun willst? Es gibt noch ein 
zweiten Entwickler (Schwerpunkt Windows) der informiert werden sollte.

Gruß
Olaf