Eine strukturierte Einführung in die Welt der .so - Files mit Tutorium habe ich auch nie besucht, sondern mir mit der Technik der Beobachtung eigene Erklärungen zusammengereimt.
Daher mögen sie unvollständig, teilweise falsch sein.
Szenario:
Ein Programm foo braucht eine Bibliothek bar (libbar.so).
Bar ist auf Versionsstand 1, und im System ist libbar.so.1.0 installiert, und es gibt ein paar Links:
libbar.so.1.0 → libbar.so.1
libbar.so.1 → libbar.so
Sehr schön alles.
Zwischenzeitlich wird libbar weiterentwickelt zu libbar.so.2.
Die Entwickler von foo haben aber besseres zu tun, als sich um die Entwicklung von libbar zu kümmern, und bekommen das nicht mit.
Außerdem ist libbar eigentlich auf allen Rechnern immer und überall installiert - daher bekommt niemand eine Fehlermeldung beim Installieren von foo.
Daß foo von bar abhängig ist ist womöglich gar nicht dokumentiert.
Vor ein paar Jahren ist es mir zum ersten Mal passiert, daß ein Programm nicht wollte, und sich über eine fehlende libXY beschwert hat.
libXY.so.Z war im System vorhanden, aber kein libXY.so - das Erzeugen des symbolischen Links genügte, um das Programm zum Laufen zu bringen.
Die Versionsnummer hinter dem .so. erlaubt es wohl, unterschiedliche, inkompatible Versionen von libXY gleichzeitig installiert zu haben.
Ob die Verwendung von .so.Z erst seit einiger Zeit üblich wurde weiß ich nicht.
Mir fiel das Vorhandensein von libXY.so.Z - libs bei fehlendem Link zu libXY.so jedenfalls erst in den letzten Jahren auf.
Womöglich gibt es eine Empfehlung nicht mehr zu Bibliotheken ohne Major-Versionsnummer zu linken.
Bislang habe ich mit selbstangelegten Links noch keine nachteiligen Erfahrungen gemacht.
Ich glaube nicht, daß es ein reines Ubuntu-Phänomen ist.
Allerdings habe ich Java direkt von Sun installiert, ohne Synaptic/Apt, da ich nicht weiß, wie man unterschiedliche Versionen (1.4, 1.5, 1.6) mit Synaptic installiert.
Ich brauche Java beruflich, und hatte noch nie Problme die Sun-Pakete unter Linux zu installieren - daher fühlte ich mich sicherer es so zu machen, wie ich es immer gemacht habe - auch wenn ich weiß, daß das selten eine gute Idee ist.
–-
Mit
slocate pstops
findest Du heraus, wo pstops ist.
Wenn es nur ein Vorkommen gibt, dann folgt daraus, daß es das ist, das verwendet wird.
Wenn Java dieses pstops aufruft, dann findet es - nach der Adam C'schen Operation - stattdessen den Wrapper, der die Postscriptdatei bearbeitet, und die problematische Zeile entfernt, und dann erst das alte pstops, das jetzt pstops.dist heißt, aufruft.
–-
Wer der eigentlcihe Übeltäter bei der ps-Frage ist weiß ich nicht.
Mein Drucker ist 17 Jahre alt, und versteht die fragliche Postscriptanweisung offenbar nicht.
Das kommt nach 17 Jahren raus?
Müßte das Filtern eigentlich der Druckertreiber erledigen?
Es sind ja wohl auch deutlich jüngere Drucker betroffen.
