Błąd w slocate

[Tomasz Kłoczko]

On Mon, 21 Jun 1999, Wojtek Slusarczyk wrote:
[..]
> BTW Jak mi by ktoś zarzucił że w RH jest group console a u nas nie ma,
> to pierwsze co bym zrobił to zerknął do Debiana, Slackware'a SuSe i popatrzył
> czy tam takowa jest; i spytał do czego jest ona potrzebna w RH i czy jej PLD
> potrzebuje i czy przypadkiem `tty' nie wystarcza.

Tak czy inaczej .. nawet gdyby w każdej dystrybucji coś było to nie może
być to argumentem gdyż pozostaje jeszcze odpowiedzieć sobie "po co to jest
?". Nie wystarczy w cimno podglądać. Trzeba to też przeanalizować i
ocenić.

Wcale nie byłbym zaskoczony kdyby w SuSe, TU, Mandrake czy kilku innych
było podobnie jak w RH. Świadczyć to raczej będzie o tym, że ludzie 
robiacy te dystrybucje nie zadają sobie pewnych pytań.

Nie wiem do czego może służyć grupa console. Ktoś coś wie na ten temat ?
Jeżeli w tym wypadku za dzień, dwa się to nie rozstrzygnie to trzeba
będzie wyciać tą grupę bez uciekania się do połowicznych rozwiązań.

Tak czy inaczej innych pakietów jest na tyle dużo że robić jest co, a małe
przegrupowanie w kolece pakietów do obróbki nieczego faktycznie tu nie
przyspieszy anie nie opóźni, a oszczędzi tylko dwukrotnego opracowywania
pakietu.

W tej chwili np. od kilku dni (w kilku podejściach) siedzę nad sharutils,
który jest potrzebny do ncurses. sharutils to niby pryszcza ale zawiera
żródła niekonserwowane chyba od 94-go czy 96-go roku i błedów jest tam
sporo (tylko część jest poprawiona w RH, więcej w Debianie ale część
rozwiązań nie pasują do tego co mamy) i wolę teraz przysiedzieć przy
sharutils i opracować to teraz kiedy widzę konkretne powiązanie z innymi
pakietami niż wypuszczać tymczasowo ncurses. Tak czy inaczej opracowanie
sharutils preędzej czy później kogoś czeka i uniknąć się tego nie da i
zmienienie kolejności tylko przyniesie straty gdyż po faktycznym
opracowaniu sharutils gdyby było to zrobione po ncurses i tak trzebaby
ponownie to wszytstko przetestować przebudowując przy okazji znowu
ncurses.

Ab ovo .. można poczekać dzień, dwa na wyjaśnienie z grupą console. W
tej chwili dużo wskazuje na to, że slocate naprawdopodoniej nie trzeba
będzie zmieniać więc niech zostanie w spokoju. Także faktyczne, poprawne i
bardziej ekonomiczne rozwiązanie z przebudowaniem baz db systemowych jest
gdzie indziej więc tym bardziej slocate nie należy ruszać (o ile powyższe
załżenia są prawdziwe) tylko próbować się skupiać na tym co przyniesie
poprawne rozwiązanie w modyfikacji czterech programów, jednego skryptu i
dwuch plików konf. do PAM (co jest i tak niezależne od obecnej zawartości
slocate).

Mam nadzieję, że powysza analiza lokalnej systuacji na styku kilku
pakietów jest poprawna i że w związku z tym wynikają z niej jasno
konkretne kierunki działań jakie można próbować dalej podejmować.

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*