On Tue, Oct 16, 2018 at 12:52:19 +0200, Adam Osuchowski wrote: >> 1. zachowując kopię instalowanych pakietów podczas ich pobierania, > > Musiałoby to być robione automatycznie podczas instalacji paczki, żeby
Ja to kiedyś rozwiązywałem swoim downloaderem w poldku, a myślałem jeszcze o jakimś serwerze proxy ze stałym storagem, ale jak słusznie Bartek zauważył, jest tak wprost opcja keep downloads. >> 2. używając snapshotów na poziomie systemu plików, > > Łoo... to jest zdecydowany overkill. Trzeba mieć LVMa albo jakiś btrfs > (tudzież inny fs ze wsparciem do snapshotów), a to w czasach powszechnej > wirtualizacji i zewnętrznego storage'u często jest zbędnym balastem. 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. Tylko widzisz, sam Jeff twierdzi, że rollback powinien być realizowany poprzez cofnięcie się do odpowiedniego snapshota (bo triggery mogą modyfikować pliki). Zresztą nie wiem nawet, czy nie twierdził również, że obecny rollback został tylko ze względu na PLD (albo przynajmniej tak zrozumiałem), no i w związku z tym on jej nie rozwija i nie naprawia. Więc wcale bym się nie zdziwił, gdyby któregoś dnia rpm5 również pozbył się tej funkcji albo koncertowo przestała działać. >> 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, bo ręczne grzebanie się > z tym jest, co najmniej, podatne na ludzkie błędy (a to się zapomni > tego zrobić, a to się skasuje zrobioną paczkę, itp.). > Wiesz może na ile mozliwe jest, żeby to zautomatyzować w przypadku rpm4 > i na ile sensowne (dające się potem zainstalować i działające) paczki > robi rpmrebuild? Właśnie rpmrebuild miałem na myśli, oglądałem go kiedyś i o ile mnie pamięć nie myli, wyglądało to dość rozsądnie (łącznie z podpisywaniem powstałych pakietów), przy czym raczej podpiąć by to trzeba na poziomie poldka, więc w razie ręcznego operowania rpmem trzeba także ręcznie sobie zadbać o 'cofkę'. > Ok, tylko musi być jakaś alternatywa. Jeżeli jesteśmy w stanie aktualne > ficzery rpma 5 (albo przynajmniej te istotne, jak repackage) ogarnąć w > rpm 4 to ok, ale jeżeli to ma być upadek z deszczu pod rynnę, to nie > opłaca się ta cała zabawa z migracją bo będziemy tak samo w dupie, tylko > może w innym jej zakątku. Nie sprawdzałem rpm.org, ale używa go wiele dystrybucji (które też dbają o różne funkcje i wygodę), a jednocześnie jest regularnie rozwijany: http://rpm.org/timeline.html - w takim razie _zgaduję_, że łaty z dystrybucji przynajmniej bywają upstreamowane, co pozwala mieć nadzieję, że nie będzie trzeba wydłubywać łat z różnych zapomnianych kątów. -- Tomasz Pala <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
