Änderung bei gettext

d4mi4n

d4mi4n

volksoperator on duty
Um einigen Fragen vorzubeugen: bei der aktuellen gettext Version hatt sich etwas geändert. Also entweder portupgrade -rf gettext durchführen oder erst schön mit pkg_delete -a bereiningen nd neu installieren.

20070318:
AFFECTS: users of devel/gettext (ie: YOU)
AUTHOR: ade@FreeBSD.org

As a result of the upgrade to gettext-0.16.1, the shared library version
of libintl has changed, so you will need to rebuild all ports that
depend on gettext (ie: most of them, sorry).

portupgrade -rf gettext
portmaster -r gettext

In addition, if you have multimedia/vlc installed, you should deinstall
it *before* either of the above commands, and reinstall it manually
afterwards - vlc erroneously installs its own version of lib/charset.alias
which will overwrite the one supplied by devel/gettext otherwise.
Zum Vergrößern anklicken....
 
Falls es ausser mir noch andere gibt, die portupgrade & Co nicht leiden können, hier ein Script was (hoffentlich) alle installierten Ports findet die gegen eine bestimmte Library gelinkt sind. Im Fall von gettext müsste die alte Lib libintl.so.6 sein..
Code: 
#!/bin/sh
if [ "$1" = "" ]; then
   echo "Usage: $0 library"
   echo "e.g.: $0 libintl.so.6"
   exit 1
fi

echo "The following ports are linked against $1:"
for port in `pkg_info -aE`; do
    for p in `pkg_info -L $port`; do
        ldd $p 2> /dev/null | grep $1 2>&1 >/dev/null
        if [ $? -eq 0 ]; then
           echo "$port (`pkg_info -oq $port`)"
           break 1
        fi
    done
done

Verbesserungsvorschläge nehm ich gerne an.

Gruss Maurice
 
moe schrieb:
Falls es ausser mir noch andere gibt, die portupgrade & Co nicht leiden können, hier ein Script was (hoffentlich) alle installierten Ports findet die gegen eine bestimmte Library gelinkt sind. Im Fall von gettext müsste die alte Lib libintl.so.6 sein..
Code: 
...

Verbesserungsvorschläge nehm ich gerne an.

Gruss Maurice
Zum Vergrößern anklicken....

Moin,

das funktioniert leider nur bedingt, weil z.B.:

Code: 
[~] # ldd /usr/local/bin/kaffeine  | grep libint
        libintl.so.6 => /usr/local/lib/compat/pkg/libintl.so.6 (0x291f5000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x29d92000)

oder

Code: 
[~] # ldd /usr/local/bin/file-roller | grep libint
        libintl.so.6 => /usr/local/lib/compat/pkg/libintl.so.6 (0x28ef1000)
        libintl.so.8 => /usr/local/lib/libintl.so.8 (0x29108000)

Gruss, Elwood
 
Was meinst du genau? Wenn man "$name-des-skriptes libint" aufruft?
Wenn ich es hier mit libintl.so.6 als Parameter aufrufe findet er nur Sachen die gegen libintl.so.6 gelinkt sind..
 
moe schrieb:
Was meinst du genau? Wenn man "$name-des-skriptes libint" aufruft?
Wenn ich es hier mit libintl.so.6 als Parameter aufrufe findet er nur Sachen die gegen libintl.so.6 gelinkt sind..
Zum Vergrößern anklicken....

Moin,

ich hätte jetzt beim grep auch libintl.so.6 eingeben können. Bei mir werden die Pakete auch mit der 6er-lib (also die alte Version) wie in den Beispielen angezeigt, die sich im compat Ordner befinden.

Sprich: Es werden auch Pakete angezeigt, die schon korrekt nach .so.8 gelinkt sind.

Warum das so ist, bzw. wo man das einstellt ist mir im Augenblick nicht ganz so klar. COMPAT-Options im Kernel oder /usr/ports/misc/compatxx ?!

Ich hab mir nun einfach damit beholfen, dass das Script mir die Infos ausgibt und ein wenig Handarbeit, damit klappt es dann auch.

Gruss, Elwood
 
Achso, jetzt versteh ich, hab mir die Ausgabe gar nicht so genau angeguckt..

Ich bin in der Wissenschaft des Linkens nicht so bewandert, glaube aber dass das es so ist, dass in einer Binary irgendwo steht welche Lib er braucht (z.B. libintl.so.6) und dann der entsprechende Pfad dazu alleine gesucht wird. Also ich glaube nicht dass er nur weil die libintl.so.6 im compat-Ordner vorhanden ist dagegen linkt.
Soll heissen, wenn er bei dir bei kaffeine beim ldd-Aufruf die libintl.so.6 anzeigt, sind auch einzelne Teile noch gegen die alte gettext-Version gelinkt. Allerdings weiß ich nicht inwieweit ldd rekursive Infos anzeigt, also möglicherweise ist kaffeine "sauber" aber eine von kaffeine benötigte Lib ist noch gegen das alte gettext gelinkt.

Was ich weiß ist, dass folgende Vorgehensweise die Liste die mein Skript ausgibt immer kleiner werden lässt:
Ich nehme irgendein Programm aus der Liste, wechsele ins entsprechende Verzeichnis und rufe dort
"make pretty-print-build-depends-list" auf. Wenn in der Ausgabe eine Abhängigkeit zu einem Port vorkommt, der auch noch in der Liste meines Skriptes steht, gehe ich erst zu dem und mache dort dasselbe.. Wenn alle Abhängigkeiten nicht gegen das alte gettext gelinkt sind, führe ich dann "make && make deinstall reinstall (dist)clean" aus, und gehe zu dem Port zurück den ich davor hatte.
Ich glaube portupgrade oder ~master tun es genauso, und die Ports die ich nach dieser Vorgehensweise neubaue erscheinen auch nicht mehr in der Liste meines Skriptes, also scheints zu funktionieren.
Ist relativ aufwendig, aber die ganzen Tools mag ich wie gesagt irgendwie nicht, und man lernt sein System auf jeden Fall besser kennen.

Gruss Maurice
 
Hallo!

Ich hatte gestern noch ein kleines Problem in dem Zusammenhang. portupgrade -rf gettext lief nicht ganz durch, weil er bei mir neon nicht neu installieren konnte (dieser sehr seltsame Fehler den ich manchmal habe, dass ein Port zwar gebaut wird, aber dann versucht er ihn zu installieren, ohne die bereits installierte Version vorher zu deinstallieren, was natürlich schief läuft, weil er - zu spät - merkt, dass der Port ja schon installiert ist).

Ich musste also erstmal neon neu installieren mit portupgrade -f neon, dann lief auch portupgrade -rf gettext problemlos durch.

Ciao.
Markus Mann
];-)
 
As a result of the upgrade to gettext-0.16.1, the shared library version
of libintl has changed, so you will need to rebuild all ports that
depend on gettext (ie: most of them, sorry).
Zum Vergrößern anklicken....
Och nööö :) Das dürfte dann fast alles sein, was neu gebaut werden muss :)
 
Schon mal auf die Idee gekommen einfach einen Eintrag in die libmap.conf zu machen statt all die Ports neu zu bauen?
 
Kamikaze schrieb:
Du musst die Abhängigkeiten von gettext nicht neu bauen.
Zum Vergrößern anklicken....

Sollte wohl gehen, keine Frage. Ich würde die Lösung aber als "Workaround" bezeichnen. Ich kenn mich: Vergesse das in 2-3 Monaten oder auch länger und wundere mich später, das nachfolgende Versionen klemmen. :)

Warum soviele.. frag ich mich manchmal auch und räume auch schon mal auf. Aber alleine an p5*, kde* und gnome* kommt eine Menge zusammen. Die BSD-Urinstallation muß so von ca. 1994-1997 in dem Dreh sein... da sammelt sich ne Menge Müll. :)

Gruss, Elwood
 
-n Schalter bei portupgrade, um nur erst mal zu gucken, was es tun würde

Elwood schrieb:
Jupp.. so ist es.... bei mir sind es mittlerweile insgesamt an die 980 Ports... Das dauert!
Zum Vergrößern anklicken....

Juchu,

ich hatte immerhin etwa 100 Ports weniger neu zu bauen,
das reißt es gewaltig raus !1ELF! :ugly:

Aber gelohnt hat es sich trotzdem!
Weil, danach rannte ports-mgmt/bpm erfreulicherweise wieder,
was es zuvor einige Zeit nicht mehr tun wollte
und ich irgendwie nicht darauf gekommen bin,
woran es hakte. :)

Manchmal muß man eben der Kiste
etwas Compiler-Spaß gönnen. :)

Mit:
Code: 
portupgrade -rf[B]n[/B] gettext
Lässt sich quasi ein Trockentestdurchlauf simulieren,
beim Schalter -n (für nicht ausführen) tut portupgrade nur so.
als würde es die Ports bauen.
So kann man sehen, wieviele Ports betroffen sind
und bei welchen es klar ist, das aus irgendwelchen Gründen
portupgrade etwas nicht machen kann.
Keine Angst bei dem Schalter -n dauert das dann auch nicht lange,
weil es die Ports ja nicht baut.

Um dann ein tatsächliches Update zu machen
muß anschließend natürlich der Schalter -n
weggelasssen werden und dann braucht das portupgrade
natürlich seine Zeit.


Gruß, Fusselbär
 
Elwood schrieb:
Sollte wohl gehen, keine Frage. Ich würde die Lösung aber als "Workaround" bezeichnen. Ich kenn mich: Vergesse das in 2-3 Monaten oder auch länger und wundere mich später, das nachfolgende Versionen klemmen. :)
Zum Vergrößern anklicken....
Ich mache das immer so und hatte noch nie ärger damit. Nur ist meine libmap.conf recht groß.
 
Bisl OT: was is eigentlich der Unterschied zwischen desktopbsd-tools und bpm ?
Gibts bei einem von beiden die Möglichkeit schön mit KlickKlick die Make Optionen auszuwählen?
Bin aufgrund einen nichtmehr mucksenden Festplatte erstmal am selber anschaun gehindert... und portupgrade dank gettext entfällt somit auch :D
 
@Kamikaze: Irgendwie verstehe ich das nicht:

1. Was genau trägst du denn in die libmap.conf z.B. im jetzt aktuellen Fall von gettext ein? Ich muß ja auch nicht unbedingt alle Ports neubauen, weil die, die noch gegen das alte gettext gelinkt sind, ja automatisch die libintl.so.6 aus /compat nehmen..

2. Was ist wenn die libintl.so.6 auch irgendwann mal aus compat rausfliegst, hast du dann nicht ein Riesenproblem?
 
Ich benutze portupgrade immer mit -u, das heißt ich sammle nichts in compat. Wenn ein Programm dann nicht mehr geht, mache ich eben den entsprechenden Eintrag in der libmap.conf. In dem Fall wäre das:
Code: 
libintl.so.6		libintl.so
.so ist immer ein Link auf die neuste Version der Libraries, so dass man die Zeile selbst dann nicht ändern muss, wenn libintl.so.7 mit libintl.so.8 abgelöst wird.
 
Kamikaze schrieb:
Ich benutze portupgrade immer mit -u, das heißt ich sammle nichts in compat. Wenn ein Programm dann nicht mehr geht, mache ich eben den entsprechenden Eintrag in der libmap.conf. In dem Fall wäre das:
Code: 
libintl.so.6		libintl.so
.so ist immer ein Link auf die neuste Version der Libraries, so dass man die Zeile selbst dann nicht ändern muss, wenn libintl.so.7 mit libintl.so.8 abgelöst wird.
Zum Vergrößern anklicken....

Moin,

danke für den Tip mit dem -u. Hatte zwischenzeitlich nun auch begriffen, daß der compat-Krempel vom portupgrade gemacht wird....

Gruss, Elwood
 
Zuletzt bearbeitet:
Kamikaze schrieb:
.so ist immer ein Link auf die neuste Version der Libraries, so dass man die Zeile selbst dann nicht ändern muss, wenn libintl.so.7 mit libintl.so.8 abgelöst wird.
Zum Vergrößern anklicken....

Aber kann das nicht zum Problem bei instabilen APIs werden? Also ich will ja nich stänkern, aber ich kann mir irgendwie nicht vorstellen, dass es eine 100%ig funktionierende einfache Lösung gibt, wenn in /usr/ports/UPDATING nur eine komplizierte steht.

Aber von mir auch Danke dafür dass ich jetzt weiß wer die Dateien in compat abgelegt hat, ich dachte das wäre irgendwas vom Basesystem..
 
Ja, das kann ein Problem werden. Wenn ein Programm mal Probleme hat, mache ich einfach ein portupgrade -fuR programmname. Das ist aber äußerst selten notwendig.

Mein Vorgehen ist wohl kaum für Server geeignet, aber für eine Desktopumgebung ist mir der Aufwand eines portupgrade -fur zu viel.
 
Ich benutze die Symlinks, die vom Portssystem angelegt werden. Ich sehe kein Problem darin, im gegenteil, denke ich es ist besser als alte Libraries in compat liegen zu haben, die vielleicht Sicherheitslücken enthalten und immer noch verwendet werden.
 
d4mi4n schrieb:
Bisl OT: was is eigentlich der Unterschied zwischen desktopbsd-tools und bpm ?
Gibts bei einem von beiden die Möglichkeit schön mit KlickKlick die Make Optionen auszuwählen?
Bin aufgrund einen nichtmehr mucksenden Festplatte erstmal am selber anschaun gehindert... und portupgrade dank gettext entfällt somit auch :D
Zum Vergrößern anklicken....

Hallo d4mi4n,

ports-mgmt/bpm bietet etwas weniger Möglichkeiten, als desktopbsd-tools
aber ich benutze bpm eigentlich nur, um mir schnell einen Überblick
zu verschaffen, wenn ich die Beschreibung zum Paket lesen möchte
und weil ich es gerne bequem habe, um schnell das Verzeichnis
des Ports zu finden, falls ich z.B. dran rumfummmeln will.

Beim Paketmanager der sysutils/desktopbsd-tools dauert das Laden etwas,
weil der Paketmanger der desktopbsd-tools etwas umfangreicher
Aktivitäten entwickelt, als bpm.

Und ich will ja meist nur schnell was nachschlagen
und dafür nehme ich den bpm, das ist schneller als
auf Freshports.org zu suchen.

Aber installieren und updaten mache ich sowieso auf der Konsole
im Normalfall mit ports-mgmt/portupgrade und bei so Sachen
wie ktorrent aus dem svn zu bauen mit selbst zurechtegfrickeltem.
net-p2p/ktorrent Port oder net-p2p/ktorrent-devel Port als Gerüst benutzen
und umstricken.
Weil ich das Gebastel nicht in das Portsverzeichnis eingebunden habe
muß ich dann eben pkg_deinstall benutzen und aus dem
Bastel-Port Verzeichnis dann make install machen.

Hat aber den Vorteil,
das ich auch den Fertig Port index verwenden
kann, falls ich das möchte. :)

Übrigens gibt es ja auch noch ports-mgmt/kports von soul_rebel. ;)

Wer richtig in den Ports rumpimpen möchte,
für den ist der wiki.bsdforen.de/Make.conf_optimieren Artikel
sicherlich sehr interessant.
Danke an Lon-kamikaze, Cheasy, Laemodost, Elwood und Gronau
für den tollen Wiki Artikel. :)


Gruß, Fusselbär
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben