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 <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
