Znowu trochę poprawek w Hiero. Skróciłem nazwę jednej zmiennej (do MAKEINST_OPTS), usunąłem dużo błędów ze skryptu instalującego i usuwającego (głównie powiązane z operacjami na wielu pakietach w jednej transakcji), skrypt instalujący powinien teraz prosić o potwierdzenie tylko przy próbie downgrade-owania jakiegoś pakietu. Przynależność jednego katalogu do paru pakietów nie jest już konfliktem. No i pewnie parę innych usprawnień których już nie pamiętam.

A, trochę zmieniłem layout Repo. Nie marnuje tyle powierzchni ekranu. Oczyściłem też przy okazji arkusz styli. Nareszcie udało mi się jakoś uzyskać identyczny (no, prawie) wygląd Repo w Mozillowatych i w Operze. Poodwracałem też kolejność wpisów w zarchiwizowanym ChangeBlogu, teraz każdy miesiąc jest spisany chronologicznie z góry na dół, żeby dawało się go "normalnie" przeglądać.

A na koniec wiadomość do Marcina C.: Twój serwer pocztowy nie chce przyjmować listów z Repo. Nie podoba mu się HELO jakim przedstawia mu się zainstalowany tu Postfix. Nie będę takimi drobnostkami zawracał teraz głowy Mojemu Ulubionemu Adminowi, bo i tak ma na głowie kłopoty z łączem (co pewnie wszyscy widzą w spowolnieniu transferów z Repo). Więc po prostu odpowiem tutaj: nie próbuj ustawiać klawiatury przez windowmanagera, bo to nie należy do jego kompetencji. Spróbuj ustawić poprawną mapę w XF86Config czy XF86Config-4 (/etc/X11), to powinno rozwiązać wszystkie problemy. Np. najistotniejsze ustawienia mojej klawiatury wyglądają tak:

    Option "XkbRules"   "xfree86"
    Option "XkbModel"   "pc105"
    Option "XkbLayout"  "pl"

Co przyniósł dzisiejszy dzień w Repo? Aktualizację Hiero i jego dokumentacji. Doszła nowa sekcja [keep] (kontrolująca nadzorowanie plików konfiguracyjnych), stripowanie i generowanie zależności wreszcie respektuje ustawienia sekcji [ban], mnóstwo poprawek w skryptach hbsinst/hbsremove, o niebo wydajniejsze i ładniejsze automatyczne generatory skryptów POSTIN/PREUN...

Przydałoby się jeszcze zoptymalizować poerpeemowską procedurę kompresowania manuali itp., ale że byłoby to czystą kosmetyką, to i sobie odpuszczę - a przynajmniej na razie.

O, w tym momencie mi prąd wysiadł. Po paru minutach wrócił. Jak się okazało, to panowie z energetyki przyszli sobie pogrzebać przy kablach i coś tam zepsuli. A że nie mam ups-a, to i nagle znalazłem się przed ciemnym monitorem, w cichym pokoju, bez świateł itp. Na szczęście mam dekoracyjne świece na biurku. Po powrocie prądu uruchomiłem maszynę w singlu i puściłem fsck, bo mi się i tak już od paru dni filesystem o to upominał. Zero błędów, fragmentacja na poziomie 2.1%. Ext3 sam się podniósł, bez problemów. A zmian w edytowanym akurat w momencie awarii pliku też nie utraciłem, vim i jego pliki .swp mnie przed tym uchroniły. Inaczej mówiąc - super, system nie ucierpiał.

Wracając do Hiero... Używam go już całkiem swobodnie na swoim systemie. Nadal mam zainstalowanego RPM-a, ale nie używam go do niczego więcej niż rozpakowywanie pakietów źródłowych i konwertowanie ich do formatu Hierophanta. Baza danych rpm coraz mniej pokrywa się z tym co faktycznie leży na dysku. Za pomocą Hiero zbudowałem już i zainstalowałem takie pakiety jak glibc, XFree86, nowe gtk+ z dodatkami, SDL z CVS i sporo innej drobnicy, jak coreutils czy gqview. A tak swoją drogą, to muszę sobie ułożyć jakiś sposób przechowywania Hierophantowych przetrwalników (odpowiedników "pakietów źródłowych"). Ponieważ każdy pakiet jest trzymany w osobnym podkatalogu, to wystarczy taki podkatalog przelecieć tarem i po sprawie... ale chciałbym sobie do tego dorobić wygodną infrastrukturę. Coś, co by działało np. jak rpm-owe "rpmbuild --rebuild"... (...)

Zacząłem pisać podstawową dokumentację Hierophanta, niestety nie mam teraz czasu by ją dokończyć. Zamieszczam też zaktualizowaną wersję Hiero z paroma przykładami do obejrzenia, a może nawet przetestowania u siebie...

Update: O dziwo, znalazłem jeszcze trochę czasu i popchnąłem dokumentację Hiero o duuuży kawałek do przodu. Została mi w sumie do zrobienia tylko część praktyczna, ale nie wiem nawet czy jest specjalnie sens, bo w połączeniu z przykładami zawartymi w paczce z Hierophantem każdy zainteresowany powinien wyczuć jak to działa... Ja tam w każdym razie sobie dzisiaj Hierophantem zbudowałem i zainstalowałem nowego Gimpa (2.0rc1). Poszło jak z płatka. A że jestem w świetnym humorze, to i gimpnąłem od razu Oficjalną Ilustrację dla HBS :) Mam nadzieję, że się podoba. Cholernie ciężko rysuje się za pomocą samej myszki :/

U mnie pada, wieje, pada, wieje. Taaa... Pierwszy dzień wiosny, co? A zresztą, ja na swój sposób lubię wiatr. A, słuchając jakiejś stacji radiowej dowiedziałem się, że w całej Polsce tak sobie "powiewa". Najgorzej w warmińsko-mazurskim. Na 191 ogólnokrajowych nocnych interwencji służb ratowniczych (czyli strażaków) tam przypadło 90 z nich. Zwalone drzewa, zablokowane drogi itp. U mnie nie było tak źle, po prostu wieje mocny wiatr. Czasem sobie trochę powyje za oknem, ale ja to lubię. Prawie jak burze i grzmoty.

A, zajrzałem dziś do działu statystyk i co ujrzały moje szaro-żółto-zielone oczęta? Ano ujrzały statystyczne 179 wizyt dziennie. Czyżby gdzieś ktoś znowu pokazał adres Repo? W Linux+ wydrukowali czy co?

No i pytanie retoryczne, które nurtuje mnie przez cały dzisiejszy dzień... Grzebałem sobie wśród starych kaset i zastanawiałem się co by było, gdyby Prodigy się tak nie zeszmaciło po albumie "Music for the jilted generation"? Bo przecież po nim obrali kurs prosto na dno. Nie chodzi mi o komercyjny sukces, bo "Firestarter" na pewno takim był, ale o jakość muzyki... "The Prodigy Experience" było bardzo fajne (zwłaszcza ta starsza edycja w czerwonej okładce), później też było fajnie, "Their Law" i "Voodoo People" to bardzo fajne kawałki, ale potem już nic dobrego nie było... Tzn. kupiłem sobie kiedyś CD "Fat of the land", nie żałuję, ale nie była to też jakość jakiej bym oczekiwał. Późniejsze różne single też nie mają tego "czegoś". Liczyłem kiedyś, że Chemical Brothers zajmie miejsce Prodigy. Bo naprawdę zespół miał szansę. Gdyby się trochę doszlifowali, zrezygnowali z tego podciągania pod niemieckie techno... Ale nie, nic z tego. Oh well, dla odprężenia włączę sobie Therapy? "Nowhere". Wiesz, że ostatnio dużo śpiewam do słuchanej muzyki? Znaczy się, wtóruję wokalistom. Tylko że ja totalnie nie umiem śpiewać :)

Lada dzień muszę się wziąć za dokumentowanie Hiero. Zbudowałem sobie nim już chyba kilkanaście pakietów, w tym takie "drobiazgi" jak gcc czy glibc. Skrypt instalujący działa już zadowalająco, miałem okazję popatrzeć parukrotnie jak sobie radzi z instalowaniem glibc, uruchamianiem skryptów okołoinstalacyjnych, usuwaniem osieroconych plików itp. Zacząłem wyłączać niektóre "prośby o potwierdzenie", bo uznałem je za godne zaufania.

Budując glibc natknąłem się na bardzo kłopotliwego buga dotyczącego hardlinków. Jeśli miałem np. pięć hardlinków wskazujących na jeden inode, a używając sekcji [ban] wyłączyłem jeden z tych plików, to w paczce lądowały czasem cztery hardlinki wskazujące właśnie na ten piąty, wyłączony i nieobecny. O dziwo, nie było to zbyt destruktywne (prawdę mówiąc paczka się rozpakowywała zupełnie normalnie), ale nie dawało mi to spokoju. No i pojawiały się warningi przy instalowaniu paczki. Więc spędziłem pół godziny na analizowaniu mojego kodu oraz kodu tarfile.py. Zrozumiałem problem i zacząłem modyfikować swój kod, tworząc dosyć złożoną klamrę warunkową rozciągającą się na spory kawałek kodu. Gdy ją skończyłem zauważyłem możliwość optymalizacji. Spodobało mi się to, więc zauważyłem jeszcze raz ;) Okazało się, że zamiast marnować pięć minut na stukanie tej cholernej klamry mogłem po prostu wyjać z różnych kawałków kodu pięć wierszy, zredukować je do jednego i umieścić u szczytu pewnej funkcji. Ironia losu. Więc zrobiłem tak, po czym okazało się że tylko pogorszyłem sprawę. Teraz bowiem hardlinki generowane były bardzo fantazyjnie, mianowicie pierwszy w paczce wskazywał na samego siebie (takie tam zawiłości formatu tar), a pozostałe hardlinki wskazywały na niego. Odniosłem nieodparte wrażenie, że te małe hardlinki świetnie się bawią przy tym "spychaniu odpowiedzialności". W tym momencie byłem już pewien, że jeśli będę dalej modyfikował kod to szybko uzyskam hardlinki tworzące struktury pierścieniowe albo wskazujące na nieistniejące inody. Więc zacząłem dogłębnie analizować wszystko, po raz kolejny. I wtedy mnie olśniło. Prawidłowe rozwiązanie sprowadzało się w sumie do odkręcenia wszystkich zmian jakie porobiłem próbując "naprawić" całość i przesunięciu jednego wiersza o parę pozycji w górę. Oczywiście rozwaliłem przy okazji parsowanie sekcji [ban], ale to zauważyłem parę zbudowanych pakietów później; na szczęście poprawka była trywialna. (...)

Uruchomiłem sobie mały skrypt na całych zasobach Repo, przekonwertował html na lany tekst a potem porównał to ze średnią ilością tekstu na wydruku A4...
...i wyszło na to, że wydrukowanie całego Repo (pomijając strony ze statystykami) na kartkach A4, używając dziesięciopunktowego fontu z "pojedynczym odstępem między wierszami", zajęłoby ponad 200 stron. A dokładniej to coś koło 260. Nie zdawałem sobie sprawy, że tyle tego już jest. A o tym, że to własnoręcznie wstukałem, to wolę nawet nie myśleć.

Tematem głównym znowu jest Hiero. Usunąłem kilka paskudnych bugów i dopracowywałem brakujące części w hbs.py. Primo, zliczana jest już wielkość pakietu i zapisywana w INFO. Secundo, wprowadziłem sensowną obsługę skryptów (pre/post)(in/un), razem z dwoma samodzielnymi automatami - jednym rejestrującym i wyrejestrowującym dokumentację Info (hurra ;), drugim zajmującym się plikami konfiguracyjnymi. Tutaj właśnie nie wiedziałem za bardzo co też mam zrobić, bo... To bardziej złożone niż może się wydawać, a na dodatek jest kilka sposobów podejścia do problemu. Generalnie chodzi o to, żeby przy instalacji nowej wersji pakietu nie zamazać sobie przypadkiem starej konfiguracji. Z drugiej strony jeśli stara konfiguracja jest "waniliowa", tzn. użytkownik jej nie zmieniał po zainstalowaniu pakietu, to nowszy pakiet powinien bez skrępowania ją nadpisać. Tak też właśnie zrobiłem. Hierophant wyszukuje sobie pliki położone w katalogach /etc, /usr/etc, /usr/local/etc (o zgodności z FHS nie chcę teraz mówić, ja po prostu starałem się pokryć te najpopularniejsze przypadki - u siebie w domu używam tylko /etc). No więc wyszukuje sobie te pliki a następnie wylicza ich sumy md5 (za takie coś można pokochać Pythona - stosowny kawałek kodu miałem gotowy w pół minuty :) i zapisuje w specjalnym pliku. Oprócz tego generuje dwa dodatki do skryptów instalacyjnych, jeden wykonywany przy instalowaniu pakietu, drugi przy jego usuwaniu. Przy usuwaniu Hiero sprawdza po kolei czy pliki konfiguracyjne zmieniły zawartość (suma md5). Jeśli wykryje że któryś plik się zmienił, to zostaje wykonany jego duplikat z rozszerzeniem .hbs_saved. Czyli po usunięciu pakietu zmienione konfigi pozostają na dysku, ze zmienionymi nazwami. Przy instalacji pakietu z kolei Hiero sprawdza, czy dla każdego pliku konfiguracyjnego nie znajdzie na dysku jego wersji .hbs_saved. Jeśli znajdzie, to używa właśnie tej starej wersji, a nową zapisuje jako .hbs_new (czy jakoś tak), komunikując to od razu użytkownikowi. (...)

Chyba wygrzebałem się z przeziębienia, choć znając mnie za parę dni znowu będę kichał. Wczoraj już łaziłem bez czapki :)
Parę osób już zaczęło mi przypominać, że obiecałem ten artykuł o GUI. Niecierpliwce jedne. A ja naprawdę po prostu nie mam zbyt wiele czasu. No i Hiero, jako mniej wymagający (a więc wdzięczniejszy), nieoczekiwanie zaabsorbował resztki mojej uwagi.

A, skoro jestem przy Hierophancie - zamieszczam nowszy snapshot. Dodałem dwa prototypowe skrypty instalujące/usuwające pakiety. Przeszły w sumie tylko symulacje, żadnych prawdziwych testów, ale chyba działają poprawnie... Skrypt instalujący uruchamia się podając mu nazwy plików z pakietami do zainstalowania (np. "hbsinst foo-1.1-2.tar bar-2.13-1.tar"), a skrypt usuwający podając nazwy zainstalowanych pakietów (tak, jak figurują w /var/lib/hbs), czyli np. "hbsremove foo bar". To, jak powiedziałem, prototypy. Objawia się to przede wszystkim dużą liczbą wyświetlanych informacji i pytań zadawanych w razie wątpliwości - oraz całkowitym brakiem jakichkolwiek opcji :)

Niedługo sobie spróbuję napisać jakiś prosty konwerter mojej bazy RPM na wpisy w Hiero, wtedy będę mógł "zarejestrować" sobie glibc i inne pakiety, a potem zacząć używać Hierophanta normalnie do zarządzania pakietami w systemie. To powinno być najlepszą procedurą usuwania błędów. A, ale wcześniej obowiązkowy backup systemu ;) Nie, Hiero nie jest aż tak niebezpieczny. Przez nieuwagę już mu pozwoliłem faktycznie zainstalować i usunąć parę pakietów i nic nie popsuł.

Dodałem jeden marcowy Sen. Nie mam zamiaru informować o zmianach jakie wprowadzam w tym akurat dziale, ale to był IMO dosyć ciekawy sen, więc nie mogłem się powstrzymać :) (...)

Ała. Głowa mnie boli. A jeśli chcę być bardziej precyzyjnym, to jakaś niewidzialna siła rytmicznie stuka niewidzialnym młotkiem w moją lewą skroń. I to tak przez większą część dnia. Nie chce mi się uśmiechać, nie chce mi się rozmawiać. Biedni są ludzie, którzy dzisiaj próbowali ze mną porozmawiać... zwykle warczałem. Po prostu nie mam nastroju do rozmowy. No i jeszcze muszę przygotować kilka dokumentów na jutro... zaraz wracam... ...TRZY GODZINY PÓŹNIEJ... No, zrobione. Jednak laserowa drukarka to nieoceniona wygoda gdy ktoś musi drukować sporo tekstu, i to regularnie. Działa cichutko, więc mogę spokojnie drukować dokumenty w samym środku nocy. Drukuje też szybko (no, niektóre ekspresowe plujki Lexmarka są szybsze, ale one palą tusz jak ruski czołg paliwo). Jest tania w eksploatacji (toner kosztuje co prawda 2-3 razy tyle co zasobnik z tuszem do plujki, lekko licząc, ale ja na jednym zasobniku wydrukuję spokojnie półtora tysiąca stron, podczas gdy atramentówka... no, lepiej nie mówić). Wydrukowany tekst jest po prostu śliczny, używanie LaTeX-a nagle stało się niesamowicie przyjemne ;) No i nie ma problemu ze wsparciem pod Linuksem. A co najważniejsze, przy dłuższych wydrukach mogę się do woli sztachać zapachem tonera wtapianego w papier pod wysoką temperaturą i doprawiać to sobie wizualnym efektem migoczących żarówek (roztapianie pigmentu ciągnie tyle watów, że zaczyna mi światło w pokoju mrugać). W sumie to chyba ten zapach tonera jest dla mnie największą zaletą. No i to, że kartki po wydrukowaniu są takie cieplutkie ;)

Ech, nic nie zrobiłem przy Hiero. Brak czasu. Chociaż nie, zrobiłem tę obsługę wielu pakietów w skrypcie instalującym, nawet udało mi się przy tym uprościć kod. Zacząłem robić skrypt usuwający, w zasadzie napisałem go już (część załatwiająca upgrade-y w skrypcie instalacyjnym to prawie identyczna funkcjonalność), teraz tylko muszę kawałki kodu oprawić w nowy skrypt. (...)

Napisałem sobie prosty skrypt instalujący pakiety HBS. Wygląda na to, że powinien działać... Teoretycznie... Niecałe 6KB, używa głównie /bin/sh, coreutils i parę razy find-a. Chyba ani razu seda :) Pisałem go tak, by ograniczyć do minimum zbędne wywoływania podprocesów i jakoś w miarę inteligentnie te wywołania porozmieszczać, tak aby skrypt radził sobie np. z podmienianiem glibc. Do tego próbowałem gdzie się da iść na uzyskanie jak największej prędkości wykonywania. Myślę, że powinno to całkiem ładnie działać. Ale trochę boję się tego używać :) Nie ufam mu, cholera wie czy nie przeoczyłem jakiegoś większego babola... On parę razy wywołuje "rm -f", raz nawet "rm -rf". Używanie tego na uprawnieniach roota byłoby bardzo nierozważne. W najbardziej ryzykownym miejscu wprowadziłem specjalny "security lock", który powinien zareagować gdyby coś się naprawdę wymknęło spod kontroli - chociaż nie widzę za bardzo jak mogłoby do czegoś takiego w ogóle dojść... Teraz pozostaje mi tylko dorobić skrypt usuwający pakiety a potem postawię sobie małe środowisko pod chroot i zacznę eksperymentować. Skrypt instalujący potrafi zainstalować pojedynczy pakiet sprawdzając zależności i konflikty plików, umie też wymienić jedną wersję pakietu na inną. Jego największą wadą jest to, że na razie obsługuje tylko jeden pakiet za jednym zamachem. Czyli nie da się w jednym wywołaniu zainstalować dwóch lub więcej pakietów. Nie żebym to uważał za jakiś wielki problemem, ale z pewnością jest to dosyć śmieszne ograniczenie. Niestety, jeśli zechcę coś z tym zrobić to kod się mooocno skomplikuje. Już teraz jest dosyć złożony, a jeśli dowalę jeszcze szkielecik potrzebny do ładnej obsługi instalowania kilku pakietów równolegle to całość może przekroczyć granicę czytelności. A może się uprości, tego nigdy nie wiadomo ;)

No i zachorowałem. Gardło mnie boli, ledwo mówię, nawet nie mam sił by kaszleć. Nos mnie piecze przy każdym oddechu. Biorę leki, może do poniedziałku się wykuruję. W skład leków które przyjmuję wchodzą jakieś takie okropne krople, muszę brać 3x dziennie po pięćdziesiąt kropli o strasznym ,"chemicznym" smaku. Zatykam palcami nos gdy je piję, potem (cały czas trzymając nos) wypijam kubek ciepłej wody, przepłukując sobie dokładnie usta każdym łykiem. Dopiero potem puszczam nos. Dzięki temu przynajmniej nie czuję tego zapachu i smaku tak wyraźnie. No i na dodatek się nie wyspałem dzisiejszej nocy, cały czas budziło mnie światło księżyca. Wyglądało na pełnię. Same niesprzyjające okoliczności. Od paru dni nie czuję też specjalnie głodu, jem raczej z przyzwyczajenia. Ale bardzo dużo piję. Nie, nie alkoholu :) Płynów. Zwykłych. Wody, herbaty... Prawie cały czas coś popijam. Nie wiem, może to przez podwyższoną temperaturę? Ale wiecznie jestem lekko spragniony.

Kolejny wpis spod znaku Hiero. Po namyśle zdecydowałem się na tego zagnieżdżonego tar-a. Posprzątałem, dokręciłem parę śrubek... Hiero generuje już ładne binarne pakiety. Teraz czas zrobić prosty skrypt który by umiał zainstalować pakiet i zarejestrować go w bazie. Potem muszę się zająć plikami konfiguracyjnymi instalowanymi np. w /etc - nie mogą przecież być tak po prostu nadpisywane. Udumałem sobie jak można obsługiwać takie pliki, ale samą procedurę będę mógł zrobić dopiero po stworzeniu podstawowych skryptów instalujących pakiety. Potem właśnie obsługa plików w /etc, to pociągnie za sobą zrobienie systemu skryptów (post|pre)(un|in)stall, wtedy dokończę obsługę patchy i w tym momencie Hiero będzie już ogólnie zdatny do normalnych zastosowań. Nie mam pojęcia jak teraz mi się będzie pisało, do tej pory grzebałem głównie w pythonowym kodzie, z pewną domieszką shella. Teraz muszę skrobać tylko skrypty shellowe, ewentualnie posiłkując się jakimiś drobnymi binarkami (które, jeśli będą potrzebne, będę musiał sam sobie napisać w C... a ja jestem przecież grafomanem, a nie koderem :) Więc może tempo moich prac spadnie. Ale jestem optymistycznie nastawiony, w końcu do tej pory szło mi niesamowicie gładko, praktycznie żadnego poważniejszego problemu nie napotkałem. Na razie nie zamieszczam nowszej wersji w Repo, zrobię to gdy jeszcze trochę dozbroję ten mój Pomysł.

Widziałem dzisiaj wieeelką chmarę małych ptaszków. Miały takie stalowo-grafitowe łebki, szyjki, ogonki i podbrzuszki ;), brązowe skrzydełka i nóżki, a dzioby brązowe albo żółtawe (to było pewnie warunkowane płcią). Nie były duże... gdyby wziąć trzy dorosłe wróble i zmiażdżyć je w jedną kulkę, to dałoby się z nich ulepić jednego takiego ptaka. Nie mam pojęcia co to był za gatunek. Nie znam się zbyt dobrze na ptakach. Przyleciały w naprawdę pokaźnej liczbie, odstawiły mi piękny pokaz akrobacji lotniczych przed oknem, po czym przypuściły atak na bezlistną, przemarzniętą jarzębinę która rośnie nieopodal. Oskubały co tam jeszcze było do oskubania i odfrunęły w kierunku południowym. Trudno opisać jak wdzięczny był ich "atak" na jarzębinę - tak trudno to opisać, że nawet nie spróbuję :) Muszę chyba sprawić sobie jakiś Atlas Ptaków Polskich. Ale to pewnie koszmarnie droga pozycja. Wszystko z kolorowymi obrazkami jest drogie :( (...)

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). (...)

Dodałem do Hierophanta obsługę [files], działa tylko w trybie replace. Dodałem też dosyć toporny mechanizm automatycznego radzenia sobie ze źródłami i patchami w FILES. Toporny, ale całkiem uniwersalny - oddziela patche od źródeł, rozróżnia źródła "primary" i "secondary" ("primary" to wszystko, co wygląda jak paczki ze źródłami, a "secondary" to pozostałe śmieci). Specjalna procedura decyduje o tym, który ze znalezionych pakietów ze źródłami zostanie uznany za ten "główny", a które za "poboczne". Hierophant automatycznie eksportuje ścieżki dostępu do tych plików w seriach zmiennych środowiskowych $SOURCE0, $SOURCE1, $PATCH0, $PATCH1 itp. Dodatkowo przy "ręcznie" zdefiniowanej sekcji [files] eksportowane są zmienne $PL0, $PL1 itp., zawierające ciągi np. "-p1", "-p0" - czyli opcje "patchlevel" przeznaczone dla konkretnego patcha. Definicja sekcji [files] wyglądać może tak:

[files]
gqview-1.4.0.tar.bz2
p2:patch1.patch
p0:inny_patch.diff
p0:dodatkowy_patch.diff.gz
dodatkowe_manuale.tar.gz

dodatkowe_manuale będą dostępne przez $SOURCE1, a patche przez $PATCH[0-2], z opcjami -pX pod $PL[0-2]. Kolejność wpisów w [files] decyduje o przyznawaniu numerków zmiennych. Patche i źródła można dowolnie mieszać, bo to dwie osobne kategorie i nie wpływają wzajemnie na swoją numerację.

A automatycznej detekcji plików nawet nie będę próbował tłumaczyć, w każdym razie powinna działać w 90% przypadków. Teraz muszę tylko jakoś dodać automatyczne nakładanie patchy, tzn. żeby autodetekcja od razu dodawała do sekcji [build] (albo [prep]) odpowiedni kod który by aplikował patche. Tutaj przydałoby się jakieś magiczne wykrywanie patchleveli, bo nie ma ich nigdzie podawanych. Teoretycznie jest to do zrobienia, ale jak to w praktyce by wyglądało... nie wiem, spróbuję i się przekonam. Wtedy np. kompilacja pojedynczych źródeł wraz z patchowaniem polegałaby na wrzuceniu paczki źródeł i paru patchy do FILES, a Hierophant powinien resztę sam zrobić. Kolejność aplikowania patchy zależy od ich nazw (sortowanie alfanumeryczne). Sorry, ale maszyny ustalającej poprawną kolejność aplikowania łatek to ja nie zrobię. Owszem, dałoby się (brute force), ale nie o to przecież chodzi. Dobra, spać idę. Dzisiejszą dłubaninę w kodzie uskuteczniałem w otoczeniu kadzidełek (darszan) i własnoręcznie sporządzonej świecy (blaszane, okrągłe pudełko po cukierkach "Butterscotch"+resztki starych świecy+własnego pomysłu knoty ze rdzeniami ze szpilek i podstawkami z małych, okrągłych... yyy... no, siakoś to zrobiłem. Bardzo profesjonalnie wygląda. Rozminąłem się z powołaniem, świece powinienem robić.). A, no i oczywiście znaczną rolę odegrała Morcheeba. Kawałek "Let Me See" konkretnie. Bardzo fajny. To jeden z niewielu gatunków muzyki od których Grepi nie ucieka.