On 2018-10-16 12:52, Adam Osuchowski wrote: > Tomasz Pala wrote: >> 1. zachowując kopię instalowanych pakietów podczas ich pobierania, > > Musiałoby to być robione automatycznie podczas instalacji paczki, żeby > było wygodne.
Feature-request do Poldka. Nie musi przecież to być w samym RPMie. > wersjach wyszło mi już kiedyś bokiem. Poza tym, tak jak sam zauważyłeś, > brak tu jest zachowania lokalnych zmian, co dla mnie jest sporą wadą, bo > jak coś modyfikuję, to po to, żeby tak właśnie było, a nie, żeby to było > nadpisane. No i nie tylko pliki z /etc się modyfikuje, czasami trzeba > i co innego, żeby dopasować. To takie rzeczy najlepiej jakimś ansiblem robić, to zawsze można wszystko od zera odtworzyć. > Poza > tym nie potrzeba mi robić snapshota z całości systemu tylko z pakietu > i wracanie z tym jest praktycznie niewykonalne. To nie tak powinno się > robić, możliwość rollbacku powinna być zaimplementowana możliwie > najbliżej samego mechanizmu zarządzania pakietami. Ale tego nie da się zrobić dobrze nie pozbywając się %pre, %post i %trigger. Nie zagwarantujesz powrotu do stanu sprzed zainstalowania pakietu jeśli przy jego instalcji i deinstalacji może się wykonywać jakiś dodatkowy kod i to jeszcze zależny od innych pakietów zainstalowanych w systemie. >> 3. używając zewnętrznych narzędzi do wyłuskania plików i złożenia z nich >> nowego rpma. > > To jest najsensowniejsze z rozwiązań bo jest najbliższe temu, co robi > teraz repackage tylko za pomocą zewnętrznego narzędzia. W sumie to nawet > jest już takie narzędzie -- rpmrebuild. Nie używałem go od lat więc nie > wiem na ile jeszcze robi to co repackage, ale jeśli robi, to jest to > światełko w tunelu. Jedyne co, to potrzeba, żeby to było uruchamiane > automatycznie przy usuwaniu/podmianie pakietu To też mógłby Poldek załatwiać. W sumie bardziej ogólne rozwiązanie mogłoby służyć do różnych celów – czy to odpalenie rpmrebuild na usuwanym pakiecie, czy zrobienie snapshota filesystemu – cokolwiek sobie admin w konfig poldka wpisze. >>> i w zasadzie jedyne co, to teraz mnie tylko zaskoczył tym kompletnym >>> brakiem wsparcia do weryfikacji podpisów paczek. >> >> Czyli mamy niebezpieczne pakiety, > > No, to jest coś co mnie przeraziło biorąc pod uwagę, że rpm5 jest od > ładnych paru lat i prawdopodobnie od początku był z tym problem. Pluję > sobie w brodę, bo trzeba było to już dawno sprawdzić, a nie naiwnie > zakładać, że jak zaimportuję rpmowi klucze publiczne, a w poldku ustawię > "signed = yes" to będzie bezpiecznie. Coś ewidentnie z tym trzeba zrobić, > niezależnie od wersji rpma, która będzie w przyszłości w PLD. Ja z lenistwa nigdy się w weryfikację pakietów nie bawiłem. Zakładam, że pakiety biorę zawsze z zaufanego źródła. Jakby mi zależało na weryfikacji, to pewnie bym to sprawdził… i się rozczarował. Fakt – nie wygląda to dobrze. > Ok, tylko musi być jakaś alternatywa. Jeżeli jesteśmy w stanie aktualne > ficzery rpma 5 (albo przynajmniej te istotne, jak repackage) Mnie się nie wydaje, żeby akurat repackage było takie istotne. Już ważniejsze jest to sprawdzanie podpisów, czy kompatybilność z pakietami z innych źródeł. Jacek _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl