Трябва ми cli инструмент (линукс), който да:
- открие разликите между две "версии" на съдържанието на папка
- подготви списък на променените файлове
- приложи списъка, така че да "синхронизира" втората папка, но по-точно на нейно копие на друга физическа машина, нямаща връзка с първата (примерно през usb стик)

Имам версия на фирмуер (rootfs на линукска система, по-точно определени папки от нея - /usr, /opt, /etc и т.н.). Знам точната версия (имам копие на папката), която има на някаква машина, дето е някъде си. Правя нова версия на фирмуера, който променя един или повече файлове (може и махне, добави, модифицира). Трябва да пакетирам и изпратя това на отдалечена машина, във формата на пакетче от изпълним файл и архив, или саморазархивиращ се архив.
Целта е когато доставят тоя файл на "старата" система и се изпълни, той да подмени/добави/махне файлове, така че да постигне състоянието, което е в новия ми билд.
Т.е. система за ъпдейтване, базирана на разликите - за да се оптимизира размера на архива (да не се праща целия rootfs имидж).
Знам че има няколко системи за такива цели (swupdate, rauc и подобни), но в конкретния случай са неприложими - отдалечената система "разбира" за момента само от "ако ми бучнеш флашка и на нея има скрипт с определено име, ще го повикам - той може да си достъпва други файлове на стика, но си е негова работа да подмени каквото иска - има достъп r/w до rootfs-а, има и достъп до флашката, да се оправя".
Не искам да правя всичкото това от нулата - искам да ползвам лек инструмент (който да може да е част от "флашката" и да не се окаже че е добавил няколко мегабайта, който всъщност съм искал да спестя с "инкременталния" ъпдейт). От едната страна искам да му дам двете папки - "нова" и "стара", и той да подготви "пакет", който да сложа на флашката и да я "пратя" (реално доставката не е през флашка, но е подобно - има механизъм да се "доставят" файлове до системата, но той е сравнително бавен и трябва да се оптимизира размера, за да се ускори "ъпдейтването" на системата).
Пробвах rsync, по-точно във варианта "--only-write-batch" и "--only-read-batch". Това е хитро - прави си бинарен файл с промените, и скрипт, който да свърши работата - супер, точно каквото ми трябва. Само че бинарния файл с данните не можах да го накарам да включи истинските данни - май само описва разлики и разчита на това, че има онлайн връзка към оригиналната машина, от която да вземе самите файлове. Може и аз да бъркам в разбирането, ще пробвам още.

Като четох попаднах на някакъв "архиватор" - dar ( http://dar.linux.free.fr/ ). Проучвам го, да видя дали ще мога да го ползвам.

Някакви идеи? Търсим лек и тестван вариант - мога да си го напиша, но предпочитам нещо изпитано в боя.

https://stackoverflow.com/questions/194 ... ry-patches

Ползвал съм bsdiff/bspatch без проблеми за моя конкретен случай.

Гледах го - трябва да го билдна за моя таргет и да видя колко голям е (частта за прилагане на пач-а). Благодаря!

Тъй, поиграх си малко, но така и не намерих нещо готово, което да пасва достатъчно добре на моята ситуация. Така че го тамъня от отделни скриптове и прост tar накрая (за новите/променените) плюс отделно списък с неща за триене (които са изчезнали като ненужни в новата версия).
Пробвах bsdiff/bspatch и по принцип е много яко нещо - промяната в една библиотека, която сама по себе си е 1.4мб стрипната, се превърна в 17кб пач ... Супер е това, ама си има и проблеми:
- за разлика от класически patch, този не проверява дали базовия (old) файл, върху който слагаш бинарния пач, е същия, от който е генериран пача... не че е принципен проблем, прави са хората да са отворени "входящия контрол" да го изнесат извън инструмента, и да се очаква ползващия, преди да прилага, да е проверил хеша на базовия (стар) файл и едва тогава да "стреля", ама си и още работа
- имам проблем с workflow-а при неговото ползване, който пак не значи нищо лошо за тул-а - тъй като има базова версия ("0"), и следващи променени ("1", "2",...), няма да ми се получи универсален пач който да може да приведе от произволна базова (0..2) в новата "3" - пач-овете са различни между 0-3, 1-3, 2-3 и т.н. Понеже не знам коя версия е на система (0? 1? 2? 3?), не мога да приложа пач-а. Или трябва да прилагам последователно (инкрементално) всичките като series, докато го докарам, което изисква да пренасям пачове от минали ъпдейти, и да разпознавам на коя версия е дадената база, или да фърлям целия файл (т.е. да се откажа от пач-а). Това си е лесно за решаване ако се подходи с ъпдейт през сървър, който получава текущата версия и връща правилния ъпдейт/пачове. Но моята ситуация е по-различна.
Това с 'series' подхода може би е най-смисленото - да се правят отделните инкременти и като се види че общият им размер надхвърли този на целия файл в новата версия, да се сменя с абсолютния нов файл. Ако в серията са описани хешовете на всяка междинна версия, лесно може да се намери кой сегмент от серията да се приложи - което е оная част с входящия контрол на bspatch-а. Но това ми звучи доста работа и доста тестване, т.е. в тая посока по-добре да мина на някоя утвърдена система - но те пък "изискват" определена информация и организация, които са пак работа.
Хромиум-а има нещо алтернативно, за което ще чета сега: http://www.chromium.org/developers/design-documents/software-updates-courgette