[linux-l] rpm's bauen

[Olaf Radicke]

Am Mittwoch, 21. Februar 2007 schrieb Volker Grabsch:
> On Tue, Feb 20, 2007 at 01:21:47AM +0100, Olaf Radicke wrote:
[...]
> > > 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.

Gut. Versuchen wir die WinProgger zu "erziehen"...

[..]
> > > > 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/

...Hatte ich mich noch nicht mit beschäftigt.
>
> [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).

In unserem Fall .odt und .dia

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

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

Gut. Was machen wir dann mit den Doku's?

 * artikel_23_create_table.sql   
 * artikel_23_doc.xml           
 * DiagrammMenueFensterStruktur.dia  
 * DatenbankDiagramm.dia  
 * Diagramm_game_tabellen.dia 



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

Okay, gute Idee.

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

...Ich bin still schweigend davon ausgegangen, das der Mono-Installer 
verwendet wurde.

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

Ja, aber mit Abhängigkeit zu einer (bestimmten) Runtime-Umgebung?

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

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?

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

Wollen wir es wirklich so kompliziert machen? Warum nicht alles 
in /opt/artikel23/* abwerfen?

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

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?

Gruß
Olaf