[packman] Re: [Packman-adm] SuSE-Verzeichnisstruktur [Was: fedora repodata]

[Ralf Corsepius]

On Fri, 2005-10-21 at 13:36 +0200, Henne Vogelsang wrote:
> Hi,
> 
> On Friday, October 21, 2005 at 11:59:40, Ralf Corsepius wrote:
> > On Fri, 2005-10-21 at 11:38 +0200, Henne Vogelsang wrote:
> > > On Friday, October 21, 2005 at 06:17:32, Ralf Corsepius wrote:
> > > > On Thu, 2005-10-20 at 18:56 +0200, Marc Schiffbauer wrote:
> > > > > * Ralf Corsepius schrieb am 20.10.05 um 14:59 Uhr:
> > > > 
> > > > > Ich finde die Struktur as-is eigendlich ganz gut,
> > > > 
> > > > Ich nicht.
> > > > 
> > > > Wenn Du Dir die Original-SuSE-Struktur ansiehst, z.B.
> > > > ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/suse/x86_64/9.3/suse/
> > > > 
> > > > Siehst Du auch dort die $basearch im Pfad:
> > > > ftp.suse.com/suse/$basearch/9.3/suse/{noarch|i586|...|src|...}/*.rpm
> > > 
> > > Naja. 
> > > 
> > > $ pwd
> > > /mounts/mirror/SuSE/ftp.suse.com/pub/suse/x86_64
> > > $ l 9.3 
> > > lrwxrwxrwx  1 root susewww 11 2005-06-29 13:59 9.3 -> ../i386/9.3/
> > > 
> > > ;)
> > >  
> > > > In der Packmanstruktur fehlt sie: 
> > > > ftp://packman.iu-bremen.de/suse/9.3/{noarch|i586|...|src|...}/*.rpm
> > > 
> > > Wo soll da der Nachteil sein? x86_64 ist nunmal biarch. Das heisst du
> > > musst immer noarch/i?86/src pakete duplizieren wenn du x86_64 eine
> > > eigene "basearch" machst.. Ob nun durch soft-, hardlinks oder durch
> > > doppelt vorhalten von daten.
> > Ja, aber ...
> > 
> > > Alle metadaten formate die wir benutzen können aber unterscheiden
> > > zwischen archs.
> > ... nicht alle Clients können es, ...
> 
> Also YaST kann es. Yum kann es.
Yum will es können, Fakt ist, der Teufel steckt im Detail

>  RedCarpet kann es. Welcher client kann
> es denn nicht?

> > >  Ich sehe den sinn nicht ganz das nochmal im filesystem
> > > abzubilden.
> > ... Einfachheit auf Clientseite (Siehe unten).
> > 
> > ... Effektivität auf Serverseite (Vereinfachte Metadaten-Generierung;
> > Ein repodata pro basearch).
> 
> Wieso ist das einfacher? Ein $repoapp aufruf anstatt zwei... 
Weniger Files pro basearch, kleinere Repos ...

> > ... Reduktion des Traffics (Mischen aller Architekturen führt zum
> > Aufblasen der Metadaten, Unnötige Architekturen in Metadaten)
> 
> Machst du x86_64 als eigene basearch blÀst du die Metadaten viel mehr
> auf weil es mehr noarch+i?86 pakete gibt als x86_64 pakete.
Was Du sagst stimmt m.E. auf Serverseite (Es spart Plattenplatz), nicht
auf aber auf Clientseite.


Nehmen wir folgende Struktur an (Entspricht deinem Vorschlag von unten):
/noarch/
/i686/
/i586/
/x86_64/
/ppc/
/repodata/ <- 

Dieses Repodata beinhaltet die Metadaten aller Architekturen

=> Es beinhaltet für einen einzelnen Client irrelevante Pakete (Ein ppc
User hat keine Verwendung für i686 Pakete, ein i586-User keine für
x86_64 oder ppc)
-> /repodata/* sind notwendigerweise grösser wie die bei der Verwendung
von basearch'ed Strukturen.

=> /repodata/ muss bei jeglicher Änderung irgendeines Paketes für
irgendeine Architektur upgedatet werden
-> Serverseitig wesentlich höhere Rate von createrepo-Calls.
-> Jeder yum-User kann es nicht vermeiden primary.xml.gz erneut zu
downloaden (Überflüssiger Traffic), ob er nun von Änderungen betroffen
ist oder nicht.
 
> > ... Fehlerträchtigkeit/Paketkonsistenz (nicht alle ix86 Pakete lassen
> > sich immer auch für x86_64 oder andere Architekturen übersetzen. 
> 
> Es geht nicht ums ÃŒbersetzen. Du kannst ix86 pakete auf x86_64
> benutzen. x86_64 ist biarch.
Du kannst aber nicht beliebige Versionen eines Paketes für
unterschiedliche multiarchs mischen.

Versuche, xxx-1.0.1.i586.rpm mit xxx-1.0.2.x86_64.rpm gleichzeitig zu
installieren, führen zu Problemen.

> > => Auseinanderdriften der Versionen für unterschiedliche Architekturen,
> > usw. usf.)
> 
> Ich wÃŒsste nicht was das mit metadaten zu tun hat :)
Siehe oben.

Der Fall tritt auf, wenn eine Paketversion auf einen
Architektur-spezifischen Bug aufläuft, und ein Update nur für eine
Architektur freigeben wird.

Ist Versionssynchronität für alle multiarch-Varianten sichergestellt
(Mag bei SuSE der Fall sein, bei Packman aber nicht unbedingt), tritt
dieser Fall nicht auf. Bei Fedora tritt er auf.

> > Der Punkt mit dem diese Diskussion offlist begann, war allerdings yum:
> > 
> > Werden basearchs eingeführt, vereinfacht sich die yum-Konfiguration
> > erheblich:
> > 
> > * Es gäbe eine einzige, gemeinsame yum-Mirrorliste für alle Versionen
> > und alle Architekturen.
> > (Eine entsprechende Fedora-Variante habe ich momentan unter
> > ftp://packman.links2linux.de/pub/packman/fedora/mirrorlist gelegt)
> 
> Die mirrorlist kann nicht einfach so aussehen?

Wenn Du meinst, dass DAS funktioniert und dass es den Usern zuzumuten
ist ...

> http://packman.iu-bremen.de/suse/$releasever/
> http://packman.rsync.zmi.at/suse/$releasever/
> ...
> 
> Intern kann yum doch mit unterschiedlichen archs umgehen....

Theoretisch schon, in der Praxis steckt der Teufel aber auch hier im
Detail. 

Ein Klassiker: Updates/Installation/Entfernen von Paketen deren Dateien
gleichzeitig den rpms mehrerer Architekturen angehören
(z.B. /usr/share/man/man1/xxx.1.gz). Alle Installer und selbst rpm haben
Probleme mit diesem Fall.

Ralf