Co by tu zmienic w PLD...

Bartosz Świątek shadzik w gmail.com
Śro, 28 Lip 2010, 15:39:06 CEST


W dniu 28 lipca 2010 15:33 użytkownik Wojciech Błaszkowski
<wojciech w blaszkowski.com> napisał:
> 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.

Sugestia kompletnie nie na temat, bo tematem jest "Co by tu w PLD
zmienić", a nie jak se skonfigurować środowisko żeby się nie obudzić z
ręką w nocniku po upgradzie.

-- 
"I'm living proof if you do one thing right in your career, you can
coast for a long time. A LOOOOONG time." -Guy Kawasaki


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