W jaki sposób rpm weryfikuje podpisy pakietów?

[Tomasz Pala]

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 <gotar at pld-linux.org>