Ist repomd evil?

[jengelh]

repomd is doch irgendwie bescheuert... guckst du:

# apt-get update mit
# -- "rpm ..." für SL-10.1
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     24348 57.6 10.0  82448 78340 pts/2    R+   16:12   0:28 apt-get update

# apt-get update mit
# -- "repomd ..." für SL-10.1 (21510 Pakete)
# -- "repomd ..." für SL-10.1 _und_ FACTORY (+19224)
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root     24483 61.9 35.2 284500 273644 pts/2   R+   16:15   0:38 apt-get update

Läuft da was mit apt schief? Wie sieht das bei smart aus? (Bei mir in der Vergangenheit: genauso beschissen, also 200MB+) Auf 'ner Kiste mit AL3dev -- yum mit 3669 Paketen im repomd-Format -- brauchen yum und smart jeweils so zwischen 70-80 MB. Dennoch braucht apt wie beschrieben bei 10.1 plus factory nur geringfügig mehr - 290. Wer ist schuld, repomd an sich (da sind ja auch verdammt viel Metainformationen drin :-( ) oder apt?

 

[rolle]

Ich hatte das Problem mit APT auch schon (Überlaufender Arbeitsspeicher und massive CPU-Last beim Paketdateneinlesen). Durch möglichst weitgehendes Vermeiden von repomd ließ sich das Problem verkleinern. Meine vermutung ist also, daß repomd schuld ist. Als Beispiel: das repomd-Repo update hat bei mir fast die vierfache Größe des rpm-Repos beim Updaten.

 

[jengelh]

Dann soll mir jetzt noch einer klar machen, warum SUSE auf repomd setzt...

 

[rolle]

Tja, kleinster gemeinsamer Nenner? Repomd ist das, was irgenwie alle Paketmanager verstehen. Oder so....

 

[traffic]

SUSE setzt nicht mehr auf repomd, sondern hatte das mal in Erwägung gezogen und nach Performanceproblemen der aller-offensichtlichsten Art wieder fallengelassen.

Das Standard-Metadatenformat bei SUSE ist und bleibt "susetags", im Volksmund als "YaST2-Repository" bekannt. apt unterstützt dieses Format aber nicht.

- Auf den Installations-CDs und -DVDs gibt es nur susetags, kein repomd
- In der Online-Quelle gibt es beides, der Schwerpunkt ist und bleibt aber susetags (nur susetags enthält Informationen über Patterns, repomd nicht)
- repomd wird angeboten, damit die Leute problemlos auch andere, nicht-SUSE-eigene Tools verwenden können (apt, yum, smart - wobei es für smart nicht mehr nötig wäre, weil smart jetzt auch susetags unterstützt)
- die Update-Quelle hat nur repomd, weil es dort auch vorher kein susetags, sondern was ganz anderes gab

Die Hauptprobleme von repomd sind:

1. Es ist XML
2. Vernünftige Fortschrittsbalken sind implementationsbedingt unmöglich (der Parser weiß im Voraus nicht, was er parsen wird und kann bestenfalls "raten")
3. repomd stellt keinerlei "du"-Informationen bereit

Punkt 3 verursacht gerade neulich erst wieder Probleme, siehe https://bugzilla.novell.com/show_bug.cgi?id=215516

Die Tatsache, dass apt jetzt repomd unterstützt, hat nichts mit SUSE, sondern eher mit Fedora zu tun. Derjenige, der das für apt implementiert hat, ist YUM-Mitautor und Fedora-Contributor. Wir SUSE-Nutzer "nehmen" das praktisch nur "mit".

 

[jengelh]

Das Standard-Metadatenformat bei SUSE ist und bleibt "susetags", im Volksmund als "YaST2-Repository" bekannt. apt unterstützt dieses Format aber nicht.
- Auf den Installations-CDs und -DVDs gibt es nur susetags, kein repomd
- In der Online-Quelle gibt es beides, der Schwerpunkt ist und bleibt aber susetags (nur susetags enthält Informationen über Patterns, repomd nicht)
- repomd wird angeboten, damit die Leute problemlos auch andere, nicht-SUSE-eigene Tools verwenden können (apt, yum, smart - wobei es für smart nicht mehr nötig wäre, weil smart jetzt auch susetags unterstützt)
- die Update-Quelle hat nur repomd, weil es dort auch vorher kein susetags, sondern was ganz anderes gab

11:52 ichi:~ > /opt/Mathematica/Executables/math
In[1]:= cd = {susetags}
Out[1]= {susetags}
In[2]:= onl = {susetags, repomd}
Out[2]= {susetags, repomd}
In[3]:= upd = {repomd}
Out[3]= {repomd}
In[4]:= Intersection[cd, onl, upd]
Out[4]= {}

Also: das ist absolut bescheuert gemacht.

2. Vernünftige Fortschrittsbalken sind implementationsbedingt unmöglich (der Parser weiß im Voraus nicht, was er parsen wird und kann bestenfalls "raten")

Fortschrittsbalken zum Parsen sind mir nicht sooo wichtig (viel besser wäre ein Fortschrittsbalken bei Smarts Dependency Resolution!). YUM scheint darüberhinaus einen Fortschrittsbalken zu haben, der da wie folgt zu gehen scheint: am Anfang der filelists.xml steht

<filelists xmlns="http://linux.duke.edu/metadata/filelists" packages="19224">

Und während der Parser so parst, kann er doch mitzählen. Ich seh da kein Problem.

 

[traffic]

11:52 ichi:~ > /opt/Mathematica/Executables/math
In[1]:= cd = {susetags}
Out[1]= {susetags}
In[2]:= onl = {susetags, repomd}
Out[2]= {susetags, repomd}
In[3]:= upd = {repomd}
Out[3]= {repomd}
In[4]:= Intersection[cd, onl, upd]
Out[4]= {}

Also: das ist absolut bescheuert gemacht.

Und wieso?

Das war schon immer so (vorher susetags + patchinfos, jetzt susetags + repomd) und hat nie jemanden gestört. Die Repos haben ja auch unterschiedliche Eigenschaften (die einen ändern sich mit jedem Patch und die anderen ändern sich nie).