Rant of the Day
Fürs Protokoll:
Wer solche Anleitungen wie hier schreibt
http://support.brother.com/g/b/downloadhowto.aspx?c=de&lang=de&prod=mfcj4510dw_us_eu_as&os=127&dlid=dlf006648_000&flang=4&type3=564
und dann noch solche RPM-Pakete anbietet, gehört eigentlich mit einem nassen Lappen geschlagen, auch wenn man Brother zu Gute halten muss, dass sie überhaupt RPMs für Linux anbieten, aber ein klein wenig professioneller könnte man dann doch zu Werke gehen.
Code:
rpm -ihv --nodeps (scanner-drivername)
Bei dem "--nodeps" stell(t)en sich mir die Nackenhaare auf, aber es sorgte dann auch dafür, dass ich mir die Pakete mal ein wenig angesehen habe.
Warum ist "nodeps" böse? Nun, entweder ignoriert es Abhängigkeiten, die nicht erfüllt sind und meist läuft dann das entsprechende Programm im Paket nicht, oder es sind alle Abhängigkeiten erfüllt, dann braucht es kein "nodeps", ganz einfach. Lässt man das --nodeps weg, dann würden fehlende Abhängigkeiten gemeldet und man könnte diese nachinstallieren, zumindest sollte das bei jedem halbwegs ordentlichen Paket der Fall sein.
Sagte ich "halbwegs ordentlich"?
Nun, es es wird noch besser:
Code:
rpm -qp --requires brscan4-0.4.3-3.x86_64.rpm
/bin/sh
/bin/sh
/bin/sh
/bin/sh
/bin/sh
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Ähm, Moment mal .... bis auf die beiden obligatorischen Abhängigkeiten,
- Das OS muss eine shell
und
- am besten noch RPM selbst haben (was für eine Installation eines RPM irgendwie logisch ist)
hat das Paket keine weiteren Abhängigkeiten. Also ist für dieses Paket, so wie es zusammengschustert wurde, das "nodeps" schon mal unnötig.
Aber es kommt _noch_ besser:
Wie kann das sein, keinerlei Abhängigkeiten ausser einer Shell? Sind da etwa nur Shellscripte drin, wohl kaum, oder?
Code:
rpm -qpl brscan4-0.4.3-3.x86_64.rpm
/etc/opt/brother
/etc/opt/brother/scanner
/etc/opt/brother/scanner/brscan4
/etc/opt/brother/scanner/brscan4/Brsane4.ini
/etc/opt/brother/scanner/brscan4/brsanenetdevice4.cfg
/etc/opt/brother/scanner/brscan4/models4
/opt/brother
/opt/brother/scanner
/opt/brother/scanner/brscan4
/opt/brother/scanner/brscan4/Brsane4.ini
/opt/brother/scanner/brscan4/brsaneconfig4
/opt/brother/scanner/brscan4/brsanenetdevice4.cfg
/opt/brother/scanner/brscan4/doc
/opt/brother/scanner/brscan4/doc/brscan4
/opt/brother/scanner/brscan4/doc/brscan4/readme.txt
/opt/brother/scanner/brscan4/models4
/opt/brother/scanner/brscan4/models4/ext_1.ini
/opt/brother/scanner/brscan4/models4/ext_10.ini
/opt/brother/scanner/brscan4/models4/ext_11.ini
/opt/brother/scanner/brscan4/models4/ext_12.ini
/opt/brother/scanner/brscan4/models4/ext_13.ini
/opt/brother/scanner/brscan4/models4/ext_14.ini
/opt/brother/scanner/brscan4/models4/ext_15.ini
/opt/brother/scanner/brscan4/models4/ext_16.ini
/opt/brother/scanner/brscan4/models4/ext_2.ini
/opt/brother/scanner/brscan4/models4/ext_3.ini
/opt/brother/scanner/brscan4/models4/ext_4.ini
/opt/brother/scanner/brscan4/models4/ext_5.ini
/opt/brother/scanner/brscan4/models4/ext_6.ini
/opt/brother/scanner/brscan4/models4/ext_7.ini
/opt/brother/scanner/brscan4/models4/ext_8.ini
/opt/brother/scanner/brscan4/models4/ext_9.ini
/opt/brother/scanner/brscan4/setupSaneScan4
/usr/bin/brsaneconfig4
/usr/lib64/sane/libsane-brother4.so
/usr/lib64/sane/libsane-brother4.so.1
/usr/lib64/sane/libsane-brother4.so.1.0.7
Neee, natürlich nicht, und es würde mich dann doch sehr wundern, wenn eine shared library (.so =
shared object) keine Abhängigkeiten zu ein paar anderen Bibliotheken hätte.
RPM ausgepackt und nachgesehen:
Code:
rpm2cpio brscan4-0.4.3-3.x86_64.rpm | cpio -idu
386 blocks
ldd usr/lib64/sane/libsane-brother4.so.1.0.7
linux-vdso.so.1 (0x00007ffe72d1e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f98ca356000)
libnsl.so.1 => /lib64/libnsl.so.1 (0x00007f98ca13e000)
libusb-0.1.so.4 => /usr/lib64/libusb-0.1.so.4 (0x00007f98c9f37000)
libm.so.6 => /lib64/libm.so.6 (0x00007f98c9c36000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f98c9a32000)
libc.so.6 => /lib64/libc.so.6 (0x00007f98c9689000)
/lib64/ld-linux-x86-64.so.2 (0x000055958150f000)
libusb-1.0.so.0 => /usr/lib64/libusb-1.0.so.0 (0x00007f98c9471000)
libudev.so.1 => /usr/lib64/libudev.so.1 (0x00007f98c925d000)
librt.so.1 => /lib64/librt.so.1 (0x00007f98c9054000)
Aha, schon eher das, was man erwarten würde. Zugegeben, die meisten Bibliotheken dürften in einer halbwegs aktuellen Distro per default schon drin sein, aber bei "libudev.so.
1" (ältere Versionen von udev haben libudev.so.0) und vor allem auch bei der "alten" libusb-0.1 würde ich nicht die Hand ins Feuer legen, dass die immer per default im System drin ist. Lustige Nebenbemerkung, ein und die selbe Binärdatei (hier = shared library) sowohl gegen die alte als auch gegen die neuere libusb (libusb-1.0) zu linken, finde ich auch etwas schräg.
Aber ist ja egal, denn da im Paket selbst diese eindeutig vorhandenen Abhängigkeiten nicht aufgeführt sind, würde der Nutzer es eh erst merken, wenn das Ganze trotz erfolgreicher Installation (egal ob mit oder ohne nodeps) nicht funktionieren will.
Nur, im Gegensatz zu einem Executable, welches sich direkt beim Aufruf mit einer passenden Meldung, "libxyz.so.A nicht gefunden" beschweren würde, dürfte das bei einer Bibliothek sehr gut versteckt in irgendeinem Syslog stehen, wenn überhaupt.
Aber, es kommt NOCH besser:
Ich baue jetzt seit einigen Jahren RPM-Pakete und ich musste auch erst mal überlegen, wie man das hinbekommen kann, denn jedes mir bekannte Buildsystem für RPM-Pakete sucht (und findet!) solche Abhängigkeiten eigentlich automatisch.
Oder anders gesagt, man müsste absichtlich manuell eingreifen, damit der Buildprozess solche Abhängikeiten _nicht_ findet bzw. sie nicht in die Metadaten des Pakets einträgt, was für mich die logischste Erklärung ist, wie so ein RPM zu Stande kommen kann, denn ein eigenes Buildsystem zu schreiben wäre extra Arbeit, ein Paket so zusammen zu stümpern erspart dem Hersteller vielleicht sogar Arbeit, weil die Installation ist ja ohne Fehlermeldung gelungen ....
(... und bei Problemen dürfen dann die Helfer in Foren anfangen zu raten, woran es denn liegen könnte, weil aus dem Paket ist ja auf Anhieb erst mal nichts heraus zu lesen).....
Und als krönenden Abschluss schafft man es noch in eine Anleitung aus gerade mal vier Zeilen einen solchen Bock
einzubauen. Ja, Verwechseln von Groß-/Kleinschreibung kann natürlich schnell mal passieren, aber mal ganz nüchtern betrachtet.
Diese Anleitung kann niemand nicht einmal nur durch einfaches Abtippen der Befehle getestet haben, so etwas würde sonst sofort auffallen.
Nun, zum Glück gibt es ja auf der Seite ein "Feedbackformular", wo ich die obigen Anmerkungen mit "blumigen" aber nicht ganz so drastischen Worten hinterlassen habe.
Auch wenn das wahrscheinlich in "Ablage P" (wie Papierkorb) landen wird, konnte ich wenigstens den gröbsten Ärger los werden und vielleicht geschieht ja sogar ein Wunder und es wird nachgebessert.
Greetz,
RM
