On Mon, Oct 15, 2018 at 20:28:42 +0200, Adam Osuchowski wrote: > Dla mnie repackage to jest bardzo fajna i ważna funkcjonalność i > rozwiązuje mi to często realne problemy w PLD, kiedy po upgradzie > coś jednak nie działa i trzeba się cofnąć. Jak to ogarnąć w rpm4? > Da się w ogóle zrobić sensownie rollback nie posiadając oryginalnej > paczki z poprzednią wersją?
Dla mnie również jest to ważne, ale w realnym świecie dzisiaj rozwiązuje się to inaczej. Znam przynajmniej 3 metody, żadna nie tak wygodna, ale Jeff wielokrotnie mówił, że repackage w rpm5 też jest skopane, bo nie potrafi wycofać zmian zrobionych triggerami, a poza tym nie zgadzają się sumy kontrolne w takim repakietowanym archiwum: 1. zachowując kopię instalowanych pakietów podczas ich pobierania, 2. używając snapshotów na poziomie systemu plików, 3. używając zewnętrznych narzędzi do wyłuskania plików i złożenia z nich nowego rpma. Dla mnie osobiście istotną cechą repackage było zachowanie zmian, jakie wprowadziłem lokalnie (np. w plikach konfiguracyjnych albo wprost podmieniając jakiekolwiek inne). Wadą samego rpma było to, że nie potrafił zrobić weryfikacji sum kontrolnych w repakietowanym archiwum (tj. "pokaż mi, co tam miałem pozmieniane względem oryginału"). I tak: ad. 1 - nie masz zachowanych lokalnych zmian (wada/zaleta); ale do plików konfiguracyjnych używa się np. etckeepera, a pozostałe zmiany są dostępne w metodzie 2, ad. 2 - nie da się cofnąć tak o do poprzedniej wersji, bo jednocześnie cofniemy zmiany w reszcie systemu (co jest abstrakcją choćby po tygodniu, nawet przy dobrze poseparowanych systemach plików, z osobnym /home i /var), lecz użyte razem z metodą 1 lub 3 pozwala sobie jakoś ręcznie poradzić po fakcie, ad. 3 - pozwala sobie poradzić, gdy nie dysponujemy ani kopią oryginalnych pakietów, ani nie mamy snapshotujących systemów plików. Wreszcie metoda 4 - skorzystanie z backupu jako podstawy do 2+3. > Mnie rpm5 już przestał wkurzać i uważam, że jest ok. Owszem, na Jak to się mówi - problem nie jest to, że jesteśmy w dupie, tylko że zaczynamy się tam urządzać. > początku było z nim kiepsko ale teraz zachowuje się w całkiem stabilnie Chyba, że nie zachowuje się całkiem stabilnie i np. rozsypie się db. Albo w jakiś pokraczny sposób "radzi" sobie z --root cośtam. > i w zasadzie jedyne co, to teraz mnie tylko zaskoczył tym kompletnym > brakiem wsparcia do weryfikacji podpisów paczek. Czyli mamy niebezpieczne pakiety, mamy niebezpieczną zawartość (SUID-y), jesteśmy niekompatybilni z resztą świata, a potrzebujemy jej z braku masy własnych pakietów, a mimo to używamy jako podstawy całej dystrybucji pakietu rozwijanego przez jedną osobę z jakimś aspergerowym syndromem w kontrze do reszty świata - nie widzisz tu problemu o wadze, odważę się stwierdzić, egzystencjalnej? Fajnie, że daliśmy mu szansę, ale minęły LATA i zapaść się pogłębia. Osobiście nie jestem w stanie budować wszystkich pakietów, jakich potrzebuję - posiłkuję się innymi dystrybucjami w nspawnie albo dockerem, ale tak również długo się nie da. Wolałbym na żywca próbować instalować obce pakiety poldkiem, choćby z jakimś wydzielonym --root. Szczególnie, gdy jest to jakiś prosty lib, który mi blokuje możliwość zbudowania pakietu (a łańcuszek zerwanych zależności skutecznie zniechęca do pracy). Nawet Debian wdrożył systemd - my będziemy się bardziej kurczowo niż oni trzymać ślepej drogi ewolucji? -- Tomasz Pala <go...@pld-linux.org> _______________________________________________ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl