[linux-l] rpm's bauen
Olaf Radicke
olaf_rad at gmx.de
Mo Feb 19 00:36:39 CET 2007
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
Mehr Informationen über die Mailingliste linux-l