[packman] [Fwd: gnupg rpm in packman]

[Ralf Corsepius]

Am Son, 2003-03-02 um 13.31 schrieb Manfred Tremmel:
> Am Sonntag, 2. März 2003 09:38 schrieb Ralf Corsepius:
> 
> > Welches Header-File? Welche SuSE-Version?
> 
> glibconfig.h
> Zu finden unter /usr/lib/glib-2.0/include/glibconfig.h und 
> /usr/lib/glib/include/glibconfig.h
So ist's auch richtig und sollte so auch konfliktfrei verwendbar sein.
(Genau da liegen sie auch unter RH - RH und SuSE installieren gtk/glib
beide nach /usr)

> SuSE 8.1 (mit allen Updates natürlich und jeder Menge Packman Paketen)
>
> > Hat SuSE das Problem immer noch nicht im Griff oder hast Du eine
> > lokale Installation von glib/gtk bzw glib2/gtk2 oder Reste davon
> > herumliegen? In früheren SuSE-Version hatte SuSE gemurkst, auf den
> 
> Das System wurde mit SuSE 8.1 neu aufgesetzt, nur mein home-Verzeichnis 
> hab ich behalten, sämtliche installationen sind ordentliche RPMs aus 
> SPEC-Files generiert, kein checkinsall oder sonstwas. Was nicht von 
> SuSE stammt, ist in aller Regel auf der Packman Seite zu finden. Unter 
> /usr/local/ findet sich nicht eine Datei, nur ein paar leere 
> Verzeichnisse.
> 
> > SuSE-8.1 fehlten wichtige Teile, ich hatte aber gedacht sie hätten es
> > mit ihren Update in der Zwischenzeit hinbekommen.
> 
> Gefehlt hat in dem Fall auch nichts, es wurde nur die falsche 
> glibconfig.h herangezogen. Keine Ahnung, ob das gxine oder SuSE 
> anzulasten ist. Ein klares umswitchen wie mit dem Setzen von $QTDIR und 
> $KDEDIR scheint ja irgendwie nicht vogesehen zu sein.
Die Grundprinzipien sind bei gtk/glib anders. QT verwendet ein
gemeinsames Wurzelverzeichnis, gtk/glib hingegen versionierte Pfade.

Beide Prinzipien haben Vor- und Nachteile. Der wesentliche Vorteil
versionierte Pfade ist die Flexibilität, der Hauptnachteil ist eine
gewisse Komplexität bei der Konfiguration.

Um diese zu vereinfachen, wurden im Laufe der Entwicklung von Gtk/Glib
verschiedene config-Tools/Scripte entwickelt, von denen sich pkg-config
etabliert hat und von gtk >= 2.0 als Standard übernommen wurde.

Deshalb verwendet gtk1 noch ein wildes Sammelsurium von config-Scripten
(glib-config, gtk-config uvm.)
# gtk-config --cflags
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
-I/usr/X11R6/include

gtk2 hingegen ausschliesslich pkg-config
# pkg-config --cflags gtk+-2.0
-I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0
-I/usr/include/pango-1.0 -I/usr/include/Xft2 -I/usr/include/freetype2
-I/usr/X11R6/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include

Das Problem daran gtk < 1.2 und gnome < 1.4 verwendeten ursprünglich von
Hause aus keine versionierten Pfade, d.h. Paketierer mussten die Pfade
entsprechend setzen, sonst funktioniert das ganze nicht. Beim Erscheinen
von gnome-2.0/gtk-1.4 wurden die alten Versionen deshalb noch einmal
überarbeitet (gnome-1.4(?)/gtk-1.2) und u.A. systematisch versionierte
Pfade eingeführt.

> > Unter RH-8.0 compiliert Dein gxine-rpm (nachdem ich den
> > SuSE-KDE-Krempel und die Requires auf Freshrpms-Rpms angepasst hatte)
> > ohne jegliche Probleme.
> 
> Das SPEC-File ohne "SuSE-KDE-Krempel" und Requires-Einträgen findet sich 
> auch im tarball selber, allerdings wird der gxine_client nicht 
> eingebunden, hab ich auf dem CVS gefixed.
Ich kannte gxine bis eben nicht ;)

> > [Davon mal abgesehen, dass das ganze Tool doch wohl noch sehr nahe an
> > einer 0.x-Version ist.]
> 
> Nichts anderes wird mit einer 0.3er Versionsnummer versprochen, wobei 
> der gxine-Forntend eigentlich recht unproblematisch läuft. Günter 
> bevorzugt gxine gegenüber der xine-ui eh schon einige Zeit

Überrascht mich nicht. Unter Gnome funktioniert xine-ui mehr schlecht
als recht ;)

>  und solange 
> das xine-mozilla-plugin nicht fertig ist, ist es immer noch die beste 
> Möglichkeit, seinem Browser nen Player unterzuschieben ;-)
> 
> PS: wem auch gxine noch zu fett ist, kann mal nen Blick auf sxfe werfen,
>     der Sourcecode hat 8.347 Byte in der aktuellen Version 0.1 vom 29.
>     Januar ;-)

Ralf