Dzisiaj usiadłem na chwilkę do Hierophanta i proszę - przeportowałem z RPM-a kompresowanie manuali, dodałem moje własne stripowanie binarek i RPM-owe (trochę przerobione i wstępnie zoptymalizowane przeze mnie, choć na pewno da się jeszcze przyspieszyć) generowanie list provides/requires. Działa bardzo fajnie :) Chcę jak najszybciej doprowadzić do stanu w którym będę mógł zacząć "normalnie" używać Hiero, wtedy wszystkie błędy powinny wyjść szybko na wierzch. W zasadzie to mogę teraz zacząć robić skrypty obsługujące instalację/usuwanie/upgrade pakietów, w Hiero wszystko jakoś(?) działa, brakuje jeszcze trochę automatyki przy nakładaniu patchy, ale to nic poważnego. Teraz czeka mnie trochę główkowania jak spakować wynikowe dane w jakiś binarny pakiet... Bo obok pliku tar z drzewkiem plików do pakietu trzeba też włączyć opis, plik z zależnosciami, skrypty... no właśnie, jak to zrobić? Nie, włączanie tych plików bezpośrednio do paczki tar odpada, dane te powinny być jak najszybciej dostępne bez babrania się z rozpakowywaniem paczki. Dodatkowo jeśli paczka by była spakowana to nie ma praktycznie możliwości by ot, tak sobie wyjąć dane. Trzeba by ją całą najpierw rozpakować. Tak robi Slackware IIRC, rozpakowuje gdzieś swoje pliki a potem je roznosi po drzewku /. Ale to mi nie odpowiada, nie po to wkładam tyle roboty w stworzenie od razu idealnego ztarowanego drzewka żeby nie wykorzystać możliwości jakie mi to dało - rozpakowania paczki od razu do /. Jedynym wyjściem jest stworzenie meta-formatu. Wziąć wszystkie te "dodatkowe" pliki, połączyć je w jeden (rozdzielając jakimś separatorem), a na końcu dolepić skompresowane drzewko plików w formacie tar.gz. Dzięki temu byłby bardzo łatwy i szybki dostęp do danych pomocniczych pakietu jak np. jego listy requires/provides, ale wyciągnięcie paczki tar również byłoby bardzo proste, w razie potrzeby wystarczyłoby jakimś edytorem usunąć poprzedzające paczkę tar dane tekstowe. Oczywiście Hierophant miałby do tego celu jakieś narzędzie na własny użytek. Takie rozwiązanie by przypominało mocno to, co zastosowano w formacie DEB, o ile się nie mylę... A może jeszcze inaczej - dwie paczki tar połączone ze sobą (wystarczy połączyć "pliki pomocnicze" w paczkę tar), dać jakiś rzucający się w oczy separator między nimi (gdyby ktoś chciał ręcznie wypruć dane z archiwum), napisać prostą binarkę która by zwracała albo pierwszą, albo drugą połówkę na stdin... tak, to powinno zadziałać. Ale wtedy równie dobrze mógłbym po prostu zrobić zagnieżdżone archiwum TAR... Hmm... To nie jest takie głupie wcale... Paczka by nie mogła być kompresowana, ale to by nie było potrzebne bo jej pod-paczka by już była zgzipowana. Używając opcji --occurrence i układając dane w paczce w odpowiedniej kolejności można osiągnąć jak najbardziej zadowalającą wydajność w dobieraniu się do danych... Muszę się z tym przespać, może jutro mnie olśni. A jeśli nic nowego mi do głowy nie przyjdzie, to zacznę kombinować z tym tarem. Jedno jest pewne - nie będę tworzył jakiegoś sprytnego nowego formatu binarnego, jak to zrobiono w RPM (cpio opakowane w... a cholera wie w co. Mieli ten sam problem, więc owinęli paczkę z plikami (cpio), a potem ją razem z tymi wszystkimi meta-danymi zapakowali w jakiś własny format. Ja wolę trzymać się albo czegoś co człowiek da radę wyedytować vim-em, albo czegoś co jest ogólnie rozpoznawanym formatem).

Aj, zauważyłem że poprzedni link do nowszej wersji Hiero wcale nie wskazywał na nowszą wersję :) Gapa ze mnie. Poprawiłem, choć to pewnie nieważne bo jest już jeszcze nowsza wersja. Sprawdziłem dwa razy - tym razem link jest poprawny :) Tak to jest jak się robi cut'n'paste zamiast myśleć ;)