Debian: dpkg robiący niechciany link w /usr/local

[arctgx]

Ostatnio, bez echa ( http://forum.linux.pl/viewtopic.php?pid=70311#p70311 ), pisałem o linku /usr/local/lib/libcairo.so.2 -> libcairo-swt.so, który nie pozwalał uruchomić się programom pisanym w GTK.

Do teraz nie rozwiązałem problemu, a jedyne co potrafię, to usunąć ten link.

Ale on co jakiś czas powstaje znowu! Doszło nawet do tego że zapuściłem skrypt, który sprawdza co 5 sekund czy ten link istnieje, a jeśli tak, to otwiera okno Xdialog z zapytaniem czy go usunąć (okno po to, by zwróciło moją uwagę). Okazało się, że linki powstają tylko przy aktualizacji niektórych pakietów, niekoniecznie wyglądających na związane z GTK, np. libcupsys2_1.3.2-1_i386.deb. Sporo jest tych pakietów.

Jak temu zapobiec, skąd może się brać taka pseudonaprawa systemu?

Nie wierzę, by instrukcje na temat tego właśnie linku znajdowały się w skryptach poinstalacyjnych poszczególnych paczek.

Wiele z Debianem nie mam do czynienia ale czemu korzystasz z wersji testing?
Skoro znalazłeś jakiś błąd to raczej powinieneś to zgłosić jako bug.
Nie dość, że musiałbyś znaleźć tu osobę która korzysta z Debiana to jeszcze z wersji testing.
Podeślij mi linka skąd pobrałeś tą wersję i jakie kroki wykonujesz aby wygenerować ten błąd. W poniedziałek zobaczę o co biega.

Mariusz

[norbert_ramzes]

www.forum.debian.pl/search.php

[arctgx]

Hmm, toż chyba Debian - nawet testing - nie są na tyle rzadko używane, bym nie spodziewał się na tym forum braku odpowiedzi. Mógłbym rzucić temat na forum debianowym, ale  gdybym był pewien, że problem ten zdarza się tylko w Debianach.

Przez jakiś czas korzystałem ze stabilnej gałęzi, ale sporo programów miało wersje bardzo opóźnione. W pewnym momencie spróbowałem testing i w większości nie sprawia ona problemów na tyle, bym musiał cofać się w całości do stable (no, może z wyjątkiem tego).

Tak się składa, że w obu przypadkach nie mam pomysłu jak wyłapać usterkę, a więc i materiału na raport o błędzie. W tym akurat nie wiem czy to dpkg tworzy link czy dpkg uruchamia coś, co sprawdza że linku w /usr/local/lib brak i go robi...

Odpaliłem strace dpkg -i libcupsys2_1.3.2-1_i386.deb &>/tmp/dpkg.log (przywracające link). Zajrzałem potem do /tmp/dpkg.log grepem:

Kod: [Zaznacz]

  archives # grep -E 'cairo|swt' /tmp/dpkg.log 
open("/var/lib/dpkg/info/libcairo2.list", O_RDONLY|O_LARGEFILE) = 7
open("/var/lib/dpkg/info/libcairo2-dev.list", O_RDONLY|O_LARGEFILE) = 7
open("/var/lib/dpkg/info/python-cairo.list", O_RDONLY|O_LARGEFILE) = 7
open("/var/lib/dpkg/info/libcairomm-1.0-dev.list", O_RDONLY|O_LARGEFILE) = 7
open("/var/lib/dpkg/info/libcairo-directfb2.list", O_RDONLY|O_LARGEFILE) = 7
open("/var/lib/dpkg/info/python-cairo-dev.list", O_RDONLY|O_LARGEFILE) = 7
open("/var/lib/dpkg/info/libcairomm-1.0-1.list", O_RDONLY|O_LARGEFILE) = 7
open("/var/lib/dpkg/info/libcairo-directfb2-dev.list", O_RDONLY|O_LARGEFILE) = 7
open("/var/lib/dpkg/info/libcairo-perl.list", O_RDONLY|O_LARGEFILE) = 7
write(8, "libc6 (>= 2.6-1), libcairo2 (>= "..., 8192) = 8192

Potem

Kod: [Zaznacz]

for i in /var/lib/dpkg/info/*; do  grep -E 'cairo' "$i" | grep local; done

z pustym wynikiem. Nie wiem zatem, gdzie szukać skryptu czy czegokolwiek, co tworzy ten link. Tyle wyciągnąłem ze swojej skromnej intuicji. Dlaczego w ogóle dpkg dobiera się do /usr/local?

Niestety, kiedy domyślną wersją jest testing, polecenie "apt-get -t stable install pakiet" kończy się informacją, że pakiet jest już w najnowszej wersji.

Paczki pobieram z sunsite.icm.edu.pl:

Kod: [Zaznacz]

  archives # cat /etc/apt/sources.list
deb     ftp://193.219.28.2/pub/Linux/debian/ testing main non-free contrib
deb-src ftp://193.219.28.2/pub/Linux/debian/ testing main non-free contrib
deb     ftp://193.219.28.2/pub/Linux/debian/ stable main

deb     http://www.debian-multimedia.org/ testing main

[norbert_ramzes]

Da się wymusić instalację pakietu w dpkg i w apt chyba też, jeśli jest tak jak piszesz albo gdy np. są "niespełnione zależności" ale tego nieradzę zwłaszcza w drugim przypadku.

Jest też fajna graficzna nakładka na dpkg pod KDE ale niepamiętam jak się nazywa.

Wydaje mi się, że nakładka wiele nie pomoże:(
Mogę pomóc tylko jeśli będziesz potrafił zreplikować ten błąd.
Mariusz

[Lorenzo]

Problem może leżeć po stronie ustawień linkera.

[arctgx]

Tak, wykonanie ldconfig przywróciło link. Teraz szukam rozwiązania - przecież nie wyrzucę całego /usr/local/lib (tzn. linii w plikach /etc/ld.so.conf.d/* - może mieć znaczenie, że akurat w pliku libc.conf? ).

[arctgx]

Kod: [Zaznacz]

  arctgx # ldconfig -p|grep 'cairo.so.2'
	libcairo.so.2 (libc6) => /usr/local/lib/libcairo.so.2
	libcairo.so.2 (libc6) => /usr/lib/libcairo.so.2

Czyżby z kolejności wynikało to, że jeśli dany program chce sobie skorzystać z libcairo.so.2, to sięga do tej w /usr/local (i w większości przypadków, czyli dla programów z dystrybucji, trafia na problemy typu "undefined symbol")?

Gdyby tak było, wystarczyłoby odwrócić kolejność, by ta z /usr/lib była domyślną. Ale jak?

Drugie pytanie może pojawić się, gdy odpalę program, dla którego skompilowałem tą w /usr/local. Jak przekazać programowi, by korzystał w pierwszej kolejności z tej biblioteki, która jest wyświetlana na drugim miejscu w ldconfig -p? Nie wykluczę przecież całego /usr/lib z LD_LIBRARY_PATH. Problem ten może się nie ujawni, gdy używana biblioteka będzie zawierała wszystko z drugiej i będzie w stanie ją zastąpić. To znowu tylko intuicyjne podejście, ale kto wie czy tak nie było do momentu, gdy ta z /usr/local była nowszą, a po którejś aktualizacji stała się tą starszą nie zawierającą już czegoś tam.

Zapodaj to na fora Debiana. Niech się chłopaki pomęczą

M.

[arctgx]

Przecież teraz udało się problem uniezależnić od dystrybucji i przypisać działaniu samego ldconfig (lub innego programu linkującego - nie orientuję się w tym prawie wcale). W każdym razie, nawet jeśli jego debianowa wersja rożni się od innych, to chyba nie na tyle, bym o konfigurację pytał tylko ludzi od Debiana.

Może skoro w końcu poznałem jakieś słowa kluczowe, czas skorzystać z wyszukiwarki czy dokumentacji, a w razie niepowodzenia (choćby, gdy tej dokumentacji nie pojmę ), wrócić z tematem ujętym mniej więcej jak ostatni mój post.

Pozdrawiam i dzięki wszystkim za próby podpowiedzi, choć temat nadal nie zamknięty.

Jeśli jedno jest linkiem do drugiego to nie powinno mieć znaczenia. Może skopiuj oryginalną bibliotekę w miejsce w którym tworzony jest link?
Jeśli jakaś funkcja wywołuje polecenie "test" to linku nie utworzy.

M.

[arctgx]

Myślę że to jest rozwiązanie równie prowizoryczne jak to, co teraz robię - usuwanie linku. No, może prócz tego że zastąpiłbym raz, a usuwać muszę wielokrotnie. Można by spróbować usunąć też cel linku w /usr/local/lib lub zmienić mu nazwę.

Wolałbym jednak w sposób praktyczny dla siebie zrozumieć działanie programów linkujących.

Sztuka dla sztuki
Obyś wybrał dobrą drogę postępowania

M.

[arctgx]

Tak czy tak, warto nie bałaganić w /usr/local. Gdybym przy budowaniu tworzył paczki debianowe, wiedziałbym skąd pochodzi trefna biblioteka i może śmiało (bardziej świadomie) bym ją po prostu wyrzucił. Teraz porządek jest bardziej ryzykowny. Od jakiegoś czasu próbuję budować z pomocą "checkinstall -D".