Co by tu zmienic w PLD...

Wojciech Błaszkowski wojciech w blaszkowski.com
Śro, 28 Lip 2010, 15:33:20 CEST


Witam,

> On Wed, Jul 28, 2010 at 14:24:07 +0200, Wojciech Błaszkowski wrote:
> > Tak w ogóle, to miast czynić gdybane założenia skupić się na tym, aby
> > obecny porządek zosyawić. Nie wiem w czym tkwi problem Waszej dyskusji o
> > stabilności.
> 
> Problem tkwi w zbyt szybkiej wymianie paczek na FTP. Taki problem
> rozwiązuje się zachowując stare paczki i pozwalając ludziom dokonać
> wyboru, co uważają za stabilne, a co nie.

Hmm.. PLD zawsze chyba będzie poligonem, na którym nie każdy żołnierz da sobie 
radę. Ja się "zabezpieczyłem" stawiając swój mirror PLD, a oprócz tego trzymam 
paczki sprzed upgrade.

> > Jeśli ktoś dąży do tego, żeby wpisać "yum upgrade -y" i wsadzić ręce do
> > kieszeni to zachęcam go do skorzystania z dobrodziejstw jakie daje
> > CentOS. Zapewne Pythona 2.6 doczeka się tam w roku przyszłym.
> > 
> > Jeśli kogś nie przeraża po wykonaniu upgradu jakiś kwaszący krzyk tego
> > czy owego programu, bo np.: trzyma sobie już używane paczki z boku, to
> > nie widzę
> 
> Problem się pojawia, gdy chcesz coś doinstalować, a to już wymaga nowych
> wersji pierdyliona libów. Więc instalujesz je pieczołowicie przez
> just-install, czasem dajesz --force żeby nadpisać pokrywające się pliki*
> i liczysz, że zadziała.
> 
> > sensu tej dyskusji. Używam PLD od 5 lat na lapku i na serwerach
> > produkcyjnych i jestem zadowolony.
> 
> [*] zasadą, pod którą mógłbym się tutaj od razu podpisać, byłoby
> separowanie z bibliotek plików niewersjonowanych. O ile z takim %doc nie
> ma żadnych problemów, o tyle umieszczenie w tym samym rpmie jeszcze
> czegoś w /etc czy /usr/share powoduje problemy z multilibem. Niedawno
> sam wydzielałem engine'y z openssl, bo zainstalowany wprost na starym
> wymusił nieplanowaną wycieczkę w celu naprawienia ssh.

Przed tym to można się zabezpieczyć jeśli środowisko do pracy umieścisz w 
vserwerze. Łatwo to to przenosić pomiędzy maszyneryjami, a i problemów z SSH 
nie ma. 

Masz więc 2 środowiska (więcej pracy) ale za to:
- na "bazie" pracuje SSH + narzędzia (zazwyczaj klieckie) do monitorowania, 
ewentualnie backupów.
- na "gueście" masz LAMP, czy co tam chcesz. Z reguły wymaga to więcej lib'ów, 
ale sytuacja w której psujesz upgradem SSH na takim gueście nie zmusza Cię do 
wycieczki do serwerowni (zakładam, że masz maszynę bez KVM / IPMI).

Może sprawdź, czy takie rozwiązanie nie byłoby dla Ciebie OK. Oczywiście zdaję 
sobie sprawę, że są sytuacje, w których takie rozwiązanie będzie nie do 
przyjęcia. Cóż, to tylko sugestia.

-- 
Pozdrawiam, Best regards, Mit freundlichen Grüßen,

Wojciech "Wojtosz" Błaszkowski
www.blaszkowski.com
GSM: +48 600 197 207
JID: wojtosz w jabber.biz.pl


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