qt-1.41

[Marcin 'Qrczak' Kowalczyk]

Sat, 6 Mar 1999, Marcin Dalecki pisze:

> A ja trzymam się twardo FHS-2 i pakuję qt do /opt/qt i koniec.
> Podobnie jak KDE do /opt/kde.

Zupełnie nie rozumiem po co akurat do /opt.

> Jak mi się znudzą to jednym pociagnięciem wyżucam :-).

Wtedy to się robi rpm -e.

> Wbrew pozorom przy tego rodzaju tropach nie trzeba nawet
> ustawiać ani QTDIR ani KDEDIR w /etc/profile. Wystraczy przed kompilacją
> komponent KDE w specu wyeksportować QTDIR=/opt/qt i to wszystko....

Właśnie kompilowałem sobie pewien mały głupi programik używający Qt. Nie
z RPMa. Oczekiwał QTDIR. Skoro tak Qt przyjęło i programy tak są napisane,
to bez wyraźnego powodu nie powinniśmy tego zmieniać. Inaczej ludzie będą
mieli rację mówiąc "nie instaluj PLD, bo to gufno, używają własnych
wynalazków i nic się pod tym nie kompiluje".

W tej chwili do liba z Qt wchodzi jedna biblioteka, a do bina jeden
program (moc). Includów jest więcej i u nas są w /usr/X11R6/include/X11/qt
- fajnie, tylko brak wspólnego korzenia dla QTDIR. Proponuję albo powrót
do /usr/lib/qt, albo symlinki w /usr/lib/qt, coby QTDIR tam ustawić.

> No OK profile musi zawierać dodatkowo coś w rodzaju
> PATH=$PATH:/opt/BLA/bin
> ale to chyba mniej dolegliwe niż zawalanie /usr/bin i /usr/lib tysiącami
> programów.
> Pamiętajmy bowiem, że przeszukiwanie katalogu jest jedą
> z najbardziej kosztownych operacji w systemie plików...

W przypadku $PATH przeszukiwanie wielu małych katalogów na pewno nie jest
szybsze niż jednego dużego, zawierającego te same pliki.

> Sądzę że jest to najczystszym rozwiązaniem albowiem powoli zaczynam 
> dostrzegać w RedHato-podobnych systemach małe przeładowanie katalogów
> /usr/bin, /usr/lib i /usr/X11R6/lib...

Po prostu instalujesz dużo rzeczy. Stanowczo wolę to niż DOSowy PATH
z dwudziestoma katalogami plus katalog zawierający batche uruchamiające
poszczególne programy, dla których szkoda miejsca w PATH. To jest Unix.

Ten szczególny Unix ma takie miłe narzędzie jak RPM, dzięki czemu
rozrzucanie programów według bin+lib+var+etc zamiast według pakietów
nie utrudnia odinstalowywania. Wciąż ułatwia ułożenie partycji: /usr
może być ro, na /var musi być miejsce, /usr/share może być współdzielone
niezależnie od typu procesora. Oraz ustawienia ścieżek w konfiguracjach:
*/bin są w PATH, /usr/share/locale jest przeszukiwane przez glibca,
/usr/man przez mana, /usr/info przez info, /usr/include przez preprocesor,
/usr/doc jest domyślne dla rpma itd.

> Podobnie np. wszystko związane z GNOME tak najlebpiej byłoby pakować do
> /opt/gnome.

Eeetam. Precz z /opt. Katalogi w /etc jeszcze mają sens, bo czyta je
człowiek, ale katalogi _w /etc_, a nie /etc, /opt/kde/etc, /opt/gnome/etc
itd. I co, chcesz /opt/gnome/man, /opt/gnome/doc, /opt/gnome/include,
/opt/gnome/bin, /opt/gnome/locale itd. i dodawanie tych wszystkich ścieżek
do konfiguracji poszczególnych programów? Bez sensu. A jeśli program ma
dwie wersje, tekstową i gnomowatą, to wspólna dla nich biblioteka ma być
w /usr/lib czy w /opt/gnome/lib?

> Zaletą /opt/BARDZODUŻY pakiet jest to że partycja dla /usr może pozostać
> dość małą.

Za to /opt musi być duża. Na jedno wychodzi.

> Natomiast w usieciowionym otoczeniu wystarczy np. KDE zainstalować na
> jednej maszynce i niechajże pragnący stosowania tegoż podmontują sobie
> /opt/kde przez NFS!.

Przecież /usr sobie podmontują przez NFS.

-- 
 __("<    Marcin Kowalczyk * qrczak w knm.org.pl http://kki.net.pl/qrczak/
 \__/       GCS/M d- s+:-- a22 C+++>+++$ UL++>++++$ P+++ L++>++++$ E->++
  ^^                W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP->+ t
QRCZAK                  5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-