[packman] Benennung von RPM's

[Ralf Corsepius]

Am Fre, 2003-03-07 um 19.14 schrieb Manfred Tremmel:
> Am Freitag, 7. März 2003 10:56 schrieb Ralf Corsepius:
> 
> > > Warum sollen die SuSE-Pakete um jeden Preis bevorzugt werden?
> >
> > Ich glaube, Du hast den Sinn und Zweck einer Distri nicht verstanden.
> >
> > Die Distri ist der "Herrscher über alles was in /usr und / liegt"
> 
> Hm, ham wir denn schon TCPA?

Wir haben aber den FHS, die LSB. und die GNU-Standards. Dort steht
eindeutig drin, was für welche Zwecke vorgesehen ist. 

Etwas vereinfacht, im Kern: 
* /, /bin, /lib, /etc und /usr für systemweite Installationen.
* /usr/local für lokale Installationen, die Vorrang vor der systemweiten
Installation haben sollen
* /opt für optionale Komponenten (Inbes. Pakete Dritter)

Ersetzen von Distri-Paketen durch Pakete aus Dritten Quellen ist darin
nicht vorgesehen aber auch nicht explizit verboten. 

Entsprechend verhalten sich SuSE (und andere Distris), d.h. sie nehmen
keine Rücksicht auf irgendjemanden (Siehe YaST2/SuSE-Update, RH/Up2date,
Ximian/red-carpet). Zumindest die wirklich RPM-basierten Installer (RH
und Ximian) lassen sich durch "geeignete" RPM-Benennungen zum Mitspielen
bewegen, mit SuSE/YaST geht es nur selten, bei älteren YaST2's überhaupt
nicht..

> > alles was Du oder Dritte installieren, sollte entweder kompatibel zur
> > Distri sein (also von der auch wieder verdrängt werden können), oder
> > aber parallel zur Distri installierbar sein.
> 
> Aber schau Dir Pakete wie MPlayer oder das bereits erwähnte 
> KDEMultimedia-Paket an. Die sind voll und ganz compatibel zu den SuSE 
> Paketen, bieten aber all die Fähigkeiten, die SuSE aus 
> urheberrechtlichen oder lizenzrechtlichen Gegebeneheiten in irgend 
> einem der Länder, in denen die Distri vertrieben wird, deaktiviert hat. 
> Wenn dann SuSE neue Versionen bereitstellt, die dann eben wieder 
> beschnitten sind, werden die wenigsten User glücklich sein, all die 
> Fähigkeiten wieder zu verlieren.
> Gerade der MPlayer, den SuSE mitliefert, der ist doch höchstens als 
> Technologiedemo zu gebrauchen.
> 
> > > Und was ist mit den kdemultimedia3-Paketen?
> > > Die würden nach deiner Version nicht berücksichtigt werden
> > > (jedenfalls nicht im automatischen Update-Prozess, wenn wir mal
> > > pinning und solche Geschichten aussen vor lassen)
> >
> > Wieso, setz die Releasenummer richtig und das wars. Sollte SuSE dann
> > einmal einen Update liefern, werden die Packman rpms wieder durch
> > SuSE rpms ersetzt, und derjenige, der bei Packman die
> > kdemultimedia-rpms baut, muss nachziehen - Nichts anderes würde ich
> > erwarten.
> 
> Mach ich eh immer, bringt SuSE eine neue Version raus, hole ich mir das 
> Source-RPM und bastle meine Änderungen wieder rein. Die ersten zwei 
> Version basierten auf den Paketen vom KDE-Server, als SuSE dann auf dem 
> eigenen FTP-Server neuere Varianten bereitstellte. Die aktuellen 
> Versionen auf dem ftp-Server von SuSE haben Build-Nummer 51, die bei 
> Packman 70 (PPC-Version ist ein bisserl älter, aber mit 266 MHz und 
> Compilerwechsel ist der Build-Prozess ne Sache von 6-7 Stunden). Sobald 
> die libxine 1-beta7 raus ist, gibts dann nochmal ne neue Version.
> 
> > Alternativ könntest Du Epoch verwenden, nur dann wirst Du die Packman
> > rpm _nie_ mehr los.
> 
> Wer will denn das ;-)
Weisst Du, ... ich bin für jedes Paket dankbar, um dass ich mich nicht
kümmern muss ... und wenn mir der Distri das abnimmt, ...

> > Das ist ein anderes Kapitel, Konflikte mit dritten RPM-Anbietern
> > kannst Du nie ausschliessen. Was wir aber können, ist den Distri zu
> > berücksichtigen.
> 
> Berücksichtigen schon, aber eine 100% Sicherheit haben wir auch nicht, 
> dass SuSE nicht genau die selbe nummerierung nimmt.
> 
> Man könnte natürlich auch sowas wie 1.0-0.packman.0 oder so verwenden.
Klar, kann man - I ch hatte bei meinen Packman rpms bisher X_l2l_Y
verwendet. 

Es hilft zumindest dabei Packman-rpms im System zu finden (rpm -qa |
grep _l2l_ ) und hilft m.E. dabei, eigene RPMs statt Packman- oder
Vendor-RPMs zu installieren. 

Bei eigenen, lokalen RPMS verwende ich "Release: X_rc_Y", was, da "l2l"
lexikalischer kleiner  "rc" ist, bei mir, mehr oder weniger zufällig 
(rc ... meine Initialen) zum gewünschten Ergebnis führt.

Ralf