[packman] Packmanrobot: automatische Requires

[Ralf Corsepius]

On Sun, 2004-07-04 at 09:37, Rainer Lay wrote:
> Moin,
> 
> 
> Ralf Corsepius wrote:
> > On Sat, 2004-07-03 at 09:42, Rainer Lay wrote:
> > 
> >>Moin,
> >>
> >>nachdem immer wieder mal ein paar requires fehlen, habe ich den Robot so 
> >>erweitert, dass er abhängig von den neu kompilierten RPMS ein Liste mit 
> >>requires Statements aufstellt.
> > 
> > Ich halte diesen Ansatz für grundfalsch.
> bin für konstruktive Kritik offen :-).
> Nochmal kurz mein Hintergrund: Ein User wollte vlc installieren. VLC hat 
> von Haus aus eine RPM Dependency Liste von ~20 RPMs. Da mein RPM nicht 
> alle auflistet, hat sich sein RPM beschwert, dass z.B. liffmpeg.so.0 und 
> libavcodec.so.0 und einige andere (file requires) fehlen. Da er nicht 
> wusste, dass avcodec in ffmpeg0.rpm ist, hat er 2 Pakete gesucht.
> Das mit den File Requires ist von der Sache richtig, es ist aber 
> manchmal schon schwer, herauszubekommen, in welchen RPMS diese Files 
> dann wirklich sind! Vor allem für Leute, die sich mit RPM Details nicht 
> auskennen, den Kommandozeilen RPM nicht mit allen -q Optionen kennen und 
> keine Lust haben, über rpm -q --whatprovides ... google ein einzelnen 
> Paket zu installieren!
> 
> > 
> > Du ersetzt File-Requires durch Packet-Requires. Dies sind funktionell 
> > grundlegend verschiedene Dinge.
> Verstanden. Macht auch Sinn. Aber für einen einfachen User schlecht 
> nachvollziehbar.
> 
> > 
> > Beispiele: 
> > * "Requires: /bin/csh" ist funktionell etwas grundlegend anderes als ein
> > "Requires: tcsh"
> > * "Requires: Mesa" ist etwas völlig anderes als ein "Requires:
> > libGL.so.1"
> Völlig richtig. (ich mach das übrigens eh nur für "lib*so*" Dateien).

Urgs, das ist mehr oder weniger der Worst-Case :-)

libX11.so.6 bleibt libX11.so.6 egal aus welchem RPM es stammt (vgl.
unten).
 
> > Darin verborgene Unterprobleme:
> > * Du verhinderst, dass Programme/Libs zwischen Paketen verschoben werden
> > können.
> > * Du verhinderst, dass Progs/Libs von unterschiedlichen Paketen bereit
> > gestellt werden können.
> 
> Die Konsequenzen sind richtig. Man könnte natürlich einfach ein neues 
> Paket bauen. Auch nicht schön.
> Wenn ich es nicht so mache, bleibt trotzdem die Frage, wie ich dem VLC 
> User beibringe, dass libavcodec.so.0 in libffmpeg0 vorhanden ist!
Zwei Möglichkeiten :-):
* Du überlässt es dem User bzw. dem von ihm verwendeten Installer (yast,
apt-get, yum) diese Abhängigkeit aufzulösen.
* Du verwendest ein Package-Requires ;-)

> > * Du gehst davon aus, dass die "Build-RPM-Umgebung" mit der
> > "Laufzeit-RPM-Umgebung" übereinstimmt.
> Naja, ich setzte auf jeden Fall vorraus, dass ich auf meinem SuSE System 
> für Leute mit SuSE baue :-)
Das meine ich nicht. 

Ich beziehe mich auf Fälle, in denen Progs/Libs durch unterschiedliche
Pakete bereitgestellt werden können, es also keine eindeutige Zuordnung
Prog/Lib->rpm gibt. 

Soll heissen, Du könntest beim Bauen des RPM ein anderes RPM installiert
haben, als es der User hat. Somit würde ein Umsetzen von "File-Requires"
auf "Package-Requires" die User auf dein Setup zwingen.

2 Fälle in denen das momentan unter FC heftige Probleme bereitet:
* XFree86 vs. xorg-x11 (Unter FC1 heissen die X11-Pakete XFree86-*,
unter FC2 heissen sie xorg-x11 und sind teilweise anders organisiert.)
* libGL.so und libGl.so.1 (XFree86 vs. xorg. vs. NVidia vs. ATI vs. ...)

Damit verwandtes, auch unter SuSE bekanntes Problem:
"Requires: libGLcore.so.1"

> > Etwas mathematischer formuliert: Du gehst davon aus, dass es eine für
> > alle Zeit gültige, eineindeutige Abbildung Prog/Lib <-> RPM gibt.
> > Diese Annahme ist falsch.
> 
> richtig.
> Aber wie löse ich sonst das Problem?

Manuell (Vgl oben) - Soll  heissen, man kann durchaus Package-Requires
verwenden, wenn man sich als Maintainer darüber im Klaren ist, welche
Konsequenzen das hat. 

Es allerdings automatisch zu machen, ist im Ansatz zum Scheitern
verurteilt und auf längere Sicht fatal.

IMHO, wäre der umgekehrte Weg der eigentlich richtige: Statische
Package-Requires vermeiden wo immer es möglich ist, und stattdessen auf
die Intelligenz von "Installern" zu setzen, um Abhängigkeiten dynamisch
aufzulösen.

Ralf