doppelt gemoppelt: Paket + Basissystem

[Tronar]

Habe soeben gemerkt, daß ein Programm, das ich via sysinstall als Binärpaket installieren wollte, schon im Basissystem vorhanden ist. Das finde ich ärgerlich. Ich hätte somit zunächst zwei gleiche, nach einem Update womöglich zwei verschiedene, Versionen desselben Programms in meinem System gehabt. Vielleicht habe ich so etwas schon mehrmals gemacht!?
Gibt es keine einfache Möglichkeit, Pakete, die schon im Basissystem vorhanden sind, auch in der Paketverwaltung als vorhanden zu kennzeichnen? Oder ggf. zumindest die Installation via pkg_add/sysinstall zu verweigern?
Irgendwie werden solche Dateien ja, im Zuge der Abhängigkeits-Checks, auch wahrgenommen. Z. B. versteht das Paketsystem, daß libpcap vorhanden und die entsprechende Abhängigkeit erfüllt ist, obwohl /lib/libpcap.so.5 zu keinem Paket gehört, sondern zum Basissystem.
Ich denke, daß ich mir so auf Dauer Probleme einhandeln kann.

Oder nicht?
Tronar

 

[d4mi4n]

Um welches tool handelt es sich dabei?

 

[Kamikaze]

Ich sehe das Problem nicht. Es gibt viele Dinge aus der Basis auch im Paketsystem. Der GCC im Basissystem kommt zum Beispiel ohne Fortran und Java Compiler. Wenn man Pakete mit den gleichen Tools installiert haben die Binaries andere Namen. Zum Beispiel gawk für das GNU-awk aus den Paketen.

 

[Daemotron]

Mal abgesehen davon, dass sich ports/Packages i.d.R. nach /usr/local installieren, während alles aus /usr/src direkt in /usr landet. Welchen Programmen der Vorzug gegeben werden soll, regelt sich über PATH.

Ob bestimmte Bibliotheken aus dem Basissystem (/usr/lib) beim Bau eines Ports herangezogen werden, oder eine (ggf. neuere) Version aus den Ports, entscheidet der jeweilige Maintainer und strickt das Makefile entsprechend. So könnte es (theoretisch) durchaus sein, dass ein Port/Package eine neuere Version der libpcap benötigt, als im Basis-System vorhanden. Als Abhängigkeit würde dann nach /usr/local/lib/libpcap.so gelinkt und das dazugehörige Package/Port als Abhängigkeit ebenfalls gezogen.

 

[Tronar]

Mal abgesehen davon, dass sich ports/Packages i.d.R. nach /usr/local installieren, während alles aus /usr/src direkt in /usr landet. Welchen Programmen der Vorzug gegeben werden soll, regelt sich über PATH.

... außer, der Pfad ist etwa in einem Skript fest verdrahtet. Dann wundert sich der Benutzer, daß die Neuinstallation eines Programms scheinbar erfolglos war.

Ob bestimmte Bibliotheken aus dem Basissystem (/usr/lib) beim Bau eines Ports herangezogen werden, oder eine (ggf. neuere) Version aus den Ports, entscheidet der jeweilige Maintainer und strickt das Makefile entsprechend.

Man sollte also nicht auf die Idee kommen, die scheinbar veraltete Programmversion aus dem Basissystem eigenmächtig zu entfernen.

Kamikaze fragt in aller Herrgottsfrühe , worin das Problem liege ...:

- Ich führe XYZ aus und befolge dabei die Ratschläge aus "man XYZ". Dumm nur, wenn die angezeigte Manpage die der anderen Version ist.

- Skripte führen zu anderen Ergebnissen als interaktive Kommandos. Wer kommt schon darauf, daß der fest eingetragene Pfad im Skript (/usr/bin/XYZ) zur Verwendung der
"falschen" Programmversion führt.

- Verschiedene User erzielen mit den gleichen Befehlen verschiedene Ergebnisse und verstehen die Welt nicht mehr.

- (to be continued)

An welchem Programm ich gestern die Feststellung machte, d4mi4n, weiß ich gar nicht mehr genau. Ich habe etliche Tools aus der net-Gruppe installiert, z. B. netcat.

Ich finde jedenfalls, das ist ein unangenehmer Fallstrick. Wenn ich Administrator eines entsprechenden Netzes wäre, müßte ich bei jeder Beschwerde zuerst überprüfen, ob der betroffene User nicht seine $PATH (ggf. auch $MANPATH, $INFOPATH) verändert hat.
Es wäre doch nicht schwer, die im Basissystem enthaltene Software von vornherein in die Paketverwaltung einzutragen (und auf so fiese kleine Funktionsunterschiede wie beim gcc ganz zu verzichten).
Oder gibt es einen besonderen Grund, gerade das nicht zu tun?

Mahlzeit
Tronar