rc-scripts upgrade error

[Tomasz Pala]

On Sat, Dec 08, 2012 at 16:54:10 +0100, Jan Rękorajski wrote:

>> http://lists.pld-linux.org/mailman/pipermail/pld-devel-en/2012-October/023274.html
> 
> Nie rozumiesz, nigdy takich triggerów najwyraźniej nie pisałeś, więc Ci

Tak mizernych faktycznie, nigdy nie pisałem.

> wytłumaczę - '-f' jest tam po to żeby po upgrade nie zostać bez
> konfiguracji interfejsów, bez -f zostaniesz z domyślnym ifcfg-eth0.

Bo każdy używa eth0 i nikt po aktualizacji tak nieistotnego pakietu, jak
rc-scripts nie przegląda konfiguracji - zakładasz naturalnie, że po
prymitywnym przeniesieniu plików wszystko będzie działać i naiwnie robisz reboot?
A nawet - domyślny eth0 da przynajmniej szansę dostać się do maszyny po
IP uzyskanym z DHCP.

Pomijając już nawet trywialną możliwość dopisania tam jeszcze jednej linijki
obsługującej specjalnie przypadek tego interfejsu. Więcej powiem - taki
wyjątek tam być powinien, bo skoro ktoś sieć miał skonfigurowaną i
przenosisz już interfejsy, to tego domyślnego eth0 z pakietu być nie
powinno (nie każdy używa, więc nie każdy nadpisze własnym - a może mieć
w static-routes wpisy odnoszące się do eth0, które w ten sposób się
aktywują).

Ale nie do tego zmierzam - skryptopisarstwo uprawiane w PLD sięgnęło już
tak uproszczonego poziomu, że zamiast się taką pseudoautomatyką chwalić,
należałoby ją zwyczajnie wyłączyć. Osobiście z obawy już od dłuższego
czasu w przypadku niektórych pakietów używałem --noscripts, bo w chwili
obecnej PLD nie różni się wiele od Dowolnej Popularnej Dystrybucji, tj.
konfiguracje niestandardowe zwykle dostają po tyłku podczas aktualizacji
i jak się nie uważa, to później się korzysta z backupów.
No ale mnie już doświadczenie nauczyło (ciągnięty na siłę tmpwatch,
kasowany wtmpx, przy robieniu systemd też mi trochę rzeczy poleciało
przez tmpfiles itp.)

> No i pokaż scenariusz  w którym ktoś może mieć tam takie pozostałości starych
> plików, które mogą coś popsuć.

W przypadku PLD? Hoho!
1. instalowanie pakietów z --noscripts (i każda inna rzeźba z force i
nodeps, gdy nie idzie czegoś zrobić normalnie z braku odpowiednich
wersji pakietów/libów/whatever na ftp bądź jak w niniejszym temacie),
2. przypadkowe pociągnięcie z backupu robionego np. rsync bez delete,
3. odpalenie z rozjechanego wolumenu.

Oczywiście żadna z tych rzeczy nie powinna wystąpić na desktopie
Kowalskiego, ale na desktopie Kowalskiego jest ubunciak jakiś.

Ale do rzeczy - po zmianie zachowania rpma należałoby przejżeć wszystkie
spece, w których taka sytuacja ma miejsce (tzn. P: coś, co później jest
w triggerach). Tego zadania nikt się nie podejmie, więc ...cóż, jednak
pełny transakcyjny rollback, uwzględniający zmiany dokonane przez
triggery, faktycznie wydaje się koniecznością.

Ale dość trollowania na dziś, dobranoc.

-- 
Tomasz Pala <gotar w pld-linux.org>