On Wed, Dec 05, 2007 at 20:53:19 +0100, Pawel Golaszewski wrote: > Pierwsze co mi przyszło do głowy to telnet choćby. Mamy przynajmniej 4 > zamienniki telneta i takich programów znajdziesz na pęczki.
Nie zgodzę się - wszystkie powinny być do jednoczesnego zainstalowania z mechanizmem selekcji defaultowego. Tym samym rozwiązałby się problem vim-zależności, na ftp mogłyby być paczki vim-perl-python-ruby-everything, vim-minimal itp. a sam vim byłby zwykłym linkiem - jednym system-wide, drugim ewentualnie w ~/bin. Tu przy okazaji problem dot. PATH; otóż pakiet setup przynosi takie coś: strstr "$PATH" /usr/local/bin || PATH="$PATH:/usr/local/bin" strstr "$PATH" "$HOME/bin" || PATH="$PATH:$HOME/bin" wg mnie to powinno być odpowiednio PATH="/usr/local/bin:$PATH (taka kolejność jest zresztą w login.defs z pwdutils) oraz $HOME/bin:$PATH (i taka kolejność wszystkiego jest zakomentowana w pam_env.conf). Druga sprawa - zaraz po sshowaniu mam: /usr/bin:/bin:/usr/sbin:/sbin:/usr/X11R6/bin:/usr/local/bin:/home/users/gotar/bin a po su na swojego użytkownika: /bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin:/home/users/gotar/bin ktoś może wie, skąd różnica? A wracając do tematu... Akurat jeśli chodzi o telneta, to być może właśnie przez niego ostatnio straciłem 3 dni, próbując zdefaultować urządzenie, które przez 3 sekundy po uruchomieniu słucha na określonym IP i porcie i w tym czasie trzeba się z nim połączyć, przejść do trybu znakowego i przerwać procedurę bootowania. Nie działało mi to ani z xterma, ani terminala, ani ssh z xterma. Zadziałało dopiero przez ssh na inny serwer z poziomu terminala tekstowego. Gdybym mógł bezproblemowo zainstalować sobie wszystkie wersje, to być może spędziłbym na tym godzinę i uniknął nudnych lektur na temat działania terminali. > Conflicts nie > jest tu poprawnym rozwiązaniem, bo powinno być możliwe proste zastępowanie > jednego drugim. Osobiście używam 2 arpingów (tego z iputils oraz tego z arping) ponieważ różnią się funkcjonalnością. I one NIE są wymienne, gdyż mają inne zestawy opcji - po takiej zamianie są duże szanse, że skrypty zeń korzystające po prostu przestaną działać. > > Bo jeśli występują _konflikty_ na poziomie plików, to są to rzecz jasna > > konflikty, ale niespecjalnie widzę normalne pakiety, które nie mogą ze > > sobą koegzystować. > > Choćby demony ineta. A niby czemu nie mogą (pomijając przyczynę wewnątrz-PLD-ową w postaci mechanizmu rc-initd)? Co szkodzi, aby przez jednego demona uruchamiać jedne serwery, a przez drugiego drugie? I jeszcze raz - w szczególności, gdy te daemony mają różną funkcjonalność, a usługi można bindować do różnych interfejsów. Powiem wiecej - w przypadku mysqla i postgresa brakuje nam możliwości jednoczesnego zainstalowania różnych wersji. Sam mam jeszcze bazy mysql 4.0.x i zero możliwości wymuszenia na klientach migracji, więc 5.0.x po prostu postawiłem na fizycznie innej maszynie, natomiast co do postgresa to mam komercyjny soft chodzący na 7.x, a sam używam funkcji dodanych w 8.0 oraz 8.2 - tym razem na szczęście na różnych maszynach. > > HTTP, M serwerów MTA, itp. po to, aby administratorzy systemów-guestów > > mogli sobie korzystać z Ich Ulobionego Serwera. > > Ale co ma do tego vserver? One przecież mają osobną bazę, więc w każdym z > vserverów możesz mieć co innego. I mam każdego np. klienta pytać na starcie, jaki zestaw demonów chce? Kompleksowa usługa polega na tym, że daję mu wszystkie, a on sam niech sobie wybierze, które uruchomić, a nie konieczności uczenia się obsługi poldka z jego przypadłościami. > > > Czyli to co teraz robimy przez provides+obsoletes. > > ...i co powinno jak najszybciej wylecieć z hukiem. > > Nie powinno. OK, czyli jak chcę mieć thttpd (od strony świata) oraz apacha (od strony LAN), to muszę kombinować. Chcę 2 arpingi - muszę kombinować. Mam udowadniać że nie jestem wielbłądem i są REALNE podstawy do tego, aby potrzebować różnych pakietów do tego samego? Mam pomysł - wstawię odpowiednie P+O do mysql i postgresa, telneta i ssh, mc i krusadera, KDE i GNOME. Bo przecież nikt ich nie używa jednocześnie, right? -- Tomasz Pala <[EMAIL PROTECTED]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
