libnsl i znowu coś do roboty :>

Tomasz Kłoczko kloczek w rudy.mif.pg.gda.pl
Pon, 21 Sie 2000, 00:52:04 CEST


Kilka dni temu przez przypadek przy okazji błędów w trakcie szykowania
obecnej wersji glibc przez to, że do wynikowego pakietu z glibc nie
trafiło libnsl w wyniku próby upgradeu pakietem glibc bez libnsl pokazała
mi się lista pakietów które wymagają tej biblioteki .. i gdzieś mnie to
tak z tyłu walneło, bo libnsl zawiera wyłacznie funkcje wspomagające
sprawy z NIS/NIS+. To co mi zaświtało w głowie to było "a po co ta tona
apliakcji linkuje się z czymś z czym sie nie powinna linkować ?".

Troche jeszcze pogrzebałem w głowie i uświadomiłem sobie, że na systemach
z libc nie wspierajacych NSS czyli wszystkie bazujace na libc 5
(np. Solaris, a także wcześniejsze Linuxy) odwólania do NIS/NIS+ są
realizowane nieco inaczej i tam rzeczywiście wszystkie aplikacje
wykonujące choćby gethostname() mają tą funkcję nie w libc jak to jest
teraz w libc 6 tylko włąsnie w libnsl.

Teraz mały eksperyment:

$ rpm -q --whatrequires libnsl.so.1        
acm-4.7-8
am-utils-6.0a16-4
gnet-1.0.3-1
blt-2.4f-3
nslint-2.0.1a1-3
procmail-3.14-4
nss_ldap-113-1
flux-0.4.1-1
sliplogin-2.1.1-3
libol-0.2.18-1
uucp-1.06.1-16
yp-tools-2.1-1
ypbind-3.3-9
ypserv-1.3.5-1
vile-X11-8.3-2.1
strace-4.2-1
pwdb-0.61-1
mysql-libs-3.22.32-6
perl-Tk-800.014-3
mysql-3.22.32-4
ffingerd-1.28-1
autofs-4.0.0pre6-1
irssi-0.7.28-4
mysql-client-3.22.32-6
opie-2.32-2
stunnel-3.8-4
irssi-GNOME-0.7.28-4
cpio-2.4.2-20
amanda-client-2.4.1p1-9
gnupg-1.0.1-2
postgresql-libs-7.0.2-2
licq-0.85-3
tcsh-6.09.00-6
webalizer-2.00_12-2
w3m-0.1.10-2
postgresql-tcl-7.0.2-2
postgresql-clients-7.0.2-2
mozilla-mailnews-5.M17-1
pam-0.72.3-3
openssh-server-2.1.1p4-1
postfix-20000531-1
mysql-devel-3.22.32-6
pavuk-0.9pl25-1
licq-qt-gui-0.85-3
smalltalk-1.7-3
mysql-3.22.32-6
postgresql-7.0.2-2
postgresql-devel-7.0.2-2
mozilla-5.M17-1
perl-5.005_03-16
nscd-2.1.3-16
sawfish-0.30.3-4
sawfish-gnome-0.30.3-4
xscorch-0.1.9-1
rlinetd-0.5.1-9

jak sie zastanowić i w każdym przypadku zadać sobie pytanie "po co dany
pakiet ma wiedzić coś o NIS/NIS+ ?" to można dość do ciekawych wnisków :)
IMHO przy dobrych wiatrach z powyższego powinno zostać tylko
nss_{nis,nisplus} (może jeszcze nscd albo am-utils a i to te
prawdopodobnie będzie do wyrugowania). Prawdopodobnie nawet z pam da sie
usunąć zależnosć od libnsl. Co najwyżej może pwdb będzie musiało być
linkowane z libnsl, bo ta biblioteka nieco omija NSS (Janek może wreszcie
możnaby się zebrać na śmiałość i usunąć wogóle z naszego pam pwdb ?).

Przed chwilą zrobiłem patcha do epic4 na autoconfa na nieco inne
sprawdzanie gethostname() i na tej podstawie podejnmowanie decyzji czy
linkować czy nie z libnsl. Podam go tu w całości żeby pokazać jak może to
wyglądać i żeby uczulić bardziej na libnsl i pokazać w jaki sposób można
próbować powyższe korygować.

diff -Nru epic4-0.9.7/configure.in epic4-0.9.7.new/configure.in
--- epic4-0.9.7/configure.in    Fri Jul  7 04:32:24 2000
+++ epic4-0.9.7.new/configure.in        Mon Aug 21 00:15:28 2000
@@ -93,9 +93,8 @@
        AC_CHECK_LIB(inet, socket, libnsl=1; LIBS="$LIBS -linet -lnsl_s",)
 fi
 
-if test -z "$libnsl"; then
-       AC_CHECK_LIB(nsl, gethostname, LIBS="$LIBS -lnsl",)
-fi
+AC_CHECK_FUNC(gethostname, ,
+       AC_CHECK_LIB(nsl, gethostname, LIBS="$LIBS -lnsl",) )
 
 AC_CHECK_LIB(sun, getpwnam, LIBS="$LIBS -lsun",)
 AC_CHECK_LIB(dgc, inet_addr, LIBS="$LIBS -ldgc",)

Jak wida patch jest prymitywny.

Jeszcze zdanie na temat tego po co to. Chodzi o to, że jeżeli więcej
aplikacji nie bedzie linkowanych z niepotzrebnymi bibliotekami to
oczywiście skutek bedzie taki że aplikacje te bedą zajmować mniej pamieci
i takze bendą się szybciej ładować. Ergo .. uzyskujemy sprawniejsze
środowsko takich palikacji.

Wygląda na to że na powyższe jeszcze mało kto zwracał uwagę czyli jest
okazja do postrzątani kolejnego kawałka bałaganu.

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*




Więcej informacji o liście dyskusyjnej pld-devel-pl