[linux-l] rpm's bauen

[Volker Grabsch]

On Tue, Feb 20, 2007 at 01:21:47AM +0100, Olaf Radicke wrote:
> Das Programm verbindet sich immer über Socket mit der DB. Egal wo sie 
> läuft. Also muss die DB 1.) auf Socket lauschen und 2.) eine Verbindung 
> darüber zulassen. Beides tut Postgres "out of the Box" nicht. Da musst 
> du mindestens zwei Config-Datei editieren, den DB-Server neu starten und 
> ggf. die Firewall anpassen.

Stimmt. Aber in diesen Dateien automatisiert rumzupfuschen ist keine
gute Idee.

> > > Ich muss also ein extra Tool machen, das der User mit peviligierten
> > > Rechten startet.
> >
> > Oder dein Tool fragt einfach das Passwort des DB-Admins ab, und
> > regelt das selbst. Und zwar ohne User-Wechsel, sondern handelt es
> > direkt mit der Datenbank aus.
> 
> Hhhmmm? Warum sollte mir eine DB ihrer Passwörter verraten?

Nicht die DB, sondern der User soll dir das root-Passwort verraten.
Per Eingabefeld, GUI, du weißt schon. Nur bitte nicht im Configfile
speichern. :-)

> > Nee, so schlimm ist es nicht. Frag doch einfach das Root-Passwort
> > ab, für die, die die DB automatisch angelegt bekommen wollen.
> 
> Wie oben schon erklärt. Es kann sein das DB-Root kein 
> Passwort-Authentifizierung hat.

Ist ja nicht weiter schlimm. Mit root-Passwort geht's trotzdem.
Erst root werden, dann su nach postgres, dann DB und DB-User
anlegen. Fertig, Root-Passwort wieder vergessen, und dann in Ruhe
die Tabellen anlegen.

> > Zielgruppe für den Quellcode sind Programmierer. Die kennen auch
> > TarGZ.
> 
> Windows-Programmierer auch? Die kennen doch meist nicht mal emacs und 
> gcc.

Auch von einem Windows-Programmierer erwarte ich gewisses Grundwissen
darüber, dass es nicht nur ZIP-Dateien, sondern auch RAR, TGZ, etc.
gibt.

Aber wiegesagt, ZIP ist auch okay. Bleiben wir lieber dabei, wenn da
bei Mono-Projekten so üblich ist. Kein Source-TGZ, sondern ein
Source-ZIP, das ist wiegesagt kein großes Problem. Nur etwas ungewohnt,
das ist alles.

> > > Nur kam mir die Überlegung, das
> > > vielleicht Leute zunächst nur die Doku sehen wollen, bevor sie sich
> > > den Rest ernsthaft ansehen.
> >
> > Dafür gibt es Webseiten.
> 
> ...Wenn man eine hat :-)

Was einfaches tut's doch auch. Siehe z.B. ein uraltes SF-Projekt von mir:

    http://voji.sourceforge.net/


[Doku]
> > Und in die Binary-ZIPs kommt es auch mit rein ... kopiert .. ist
> > ja nichts ungewöhnliches, normalerweise liegt das Benutzerhandbuch
> > im src-Paket als Texinfo, LaTeX oder sowas vor, und im Binary-Paket
> > dann entsprechend als PDF/HTML/manpage.
> 
> Und der Rest der Doku bleibt in dem Paket?

Sorry, ich verstehe deine Frage nicht. Ich versuche es einfach nochmal,
mit anderen Worten zu erklären, vielleicht beantwortet das deine Frage
schon.

Meistens hat die Doku selbst auch einen Quellcode (z.B. LaTeX), der
übersetzt werden muss (z.B. nach PDF).

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.

Beim Übersetzen werden die Binaries generiert, und auch die Doku.
Das gelangt dann ins Binary-Paket, zusammen mit dem Rest der Doku,
der nicht extra generiert werden muss. (README, HTML-Doku, OpenOffice-
Dokumente, etc.).

Nur dann, wenn die Doku riesig ist und für den Normalbetrieb nicht
unbedingt nötig (z.B. komplette API-Referenzen irgendwelcher Libs),
dann erzeugt man gesonderte Doku-Pakete. Das Binary-Paket enthält dann
nur eine Mini-Doku (z.B. ne Kurzreferenz, oder sogar nur die README),
und der Rest ist als separates Paket verfügbar.

Bei einem Projekt in der Größenordnung von artikel_23 jedoch ergibt
ein separates Doku-Paket einfach keinen Sinn.

Mein Vorschlag:
    - kein Doku-Paket
    - Doku ins Source-Paket packen
    - Binär-Paket nicht im SVN verwalten, sondern automatisch erzeugen
      lassen ("make dist-bin" oder so)
    - Doku automatisch mit ins erzeugte Binary-ZIP packen.

> > Das RPM-Paket sollte mit dem Mono-RPM-Paket zusammenarbeiten, und
> > erstmal mit niemanden sonst. (wäre sonst auch reichlich sinnlos, so
> > ein RPM, wenn es von nicht-RPM-Paketen abhängig wäre)
> >
> > Auch die Dependencies würden dann so gestaltet sein, dass es vom
> > Mono-RPM und dem npgsql-RPM abhängt. Deren genaue Namen müsste ich
> > aber mal in Erfahrung bringen.
> 
> 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. :-)

> Aber ich bin im Zweifel, ob das Paket eine Mono-Abhängigkeit haben 
> sollte. Wenn der User immer die Neuste Version von Mono installiert, 
> weiß RPM nichts davon und der User ärgert sich, das mein Paket auf eine 
> alte RPM-Version beharrt. 

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.

> > > Es gibt kein /home bei Windows.
> >
> > Okay, dann siehe oben. Könntest du solch einen Mechanismus bei dir
> > einbauen?
> 
> Vielleicht will der User sein Programm auf einen USB-Stick speichern und 
> im Internet-Cafe arbeiten - was dann?

Fallback. Erst im aktuellen Verzeichnis suchen. Liegt dort keine
Konfiguration, pack sie ins APPDATA.

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

> > > > 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.
[...]
> Du bist frei geschaltet.

Danke. Hab schon ein ordentliches Makefile beigesteuert und dein
make.sh entsprechend angepasst.

> > > Du weist das der sche** SVN-Copy-Befehl bei SF.Net nicht
> > > funktioniert?
> >
> > Nein, sorry, das letzte Mal, als ich richtig aktiv SF-Projekte hatte,
> > da war 11.-12. Klasse ... damals bot SF.net gerade mal CVS an.
> 
> Okay. Das bedeutet wenn du was verschieben willst kannst du das *leider* 
> nicht mit copy, sondern du musst das Element exportieren, und an der 
> Neuen stelle wieder dem SVN bekannt machen. Dabei geht die ganze 
> History verloren. Deswegen wie bei cvs einen Vermerk in's Log wo das 
> gute Stück mal her kam. Danach das Objekt am Ursprungsort löschen.

Nö, nicht nötig. Die Projekte liegen eh alle auf Eis. Kein Bedarf nach
Konvertierung. Die hatten ihre letzten Releases vor Jahren. Würde ich
irgendeines dieser Projekte nochmal ins Leben zurück rufen, wäre der
erste Schritt wahrscheinlich sowieso eine Reimplementierung. :-)

Trotzdem danke für die Anleitung.

> In .Net gibt es dann noch solche Geschichte...
>   Application.UserAppDataPath
> 
> Die Zeile...
> Console.WriteLine
> (
>    "### Application.UserAppDataPath: " 
>    + Application.UserAppDataPath
> );
> 
> Gibt bei mir (unter Linus) zurück....
> ### 
> Application.UserAppDataPath: /home/or/.config/artikel_23/artikel_23/0.0.0.0

Super! Sowas verwisse ich leider in Python.
Genau diese Funktion solltest du nutzen.


Viele Grüße,

    Volker

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