Dziś wydałem pierwszą wersję "TiltOS for Haiku". Jest to repozytorium pakietów (oparte na projekcie pingwinek) dostępne dla systemu operacyjnego HaikuOS. Aktualnie zawiera ono ponad 100 pakietów, które można instalować bezpośrednio przez sieć. Więcej szczegółów można znaleźć w oficjalnym ogłoszeniu.
Już bardzo dawno nie pojawił się wpis na tym blogu. Pora to zmienić i pisać częściej na temat rozwoju dystrybucji linuksa Pingwinek. Aby lepiej informować Was co się dzieje w Pingwinku postanowiłem uczynić to w sposób mniej formalny używając mikroblogingu. Po świeże informacje zapraszam na kanał "Pingwinek" - http://plom.pl/channel/Pingwinek/
PS. Proszę nie hakować tego młodego serwisu. Hmm a właściwie to czemu nie? ;)
Pewnie niektórzy z was znają command-not-found z Debiana/Ubuntu. Działa to tak, że po wpisaniu nieistniejącej komendy w bashu sprawdzane jest czy nie istnieje ona w jakimś pakiecie dostępnym do zainstalowania. Jeśli tak to jest wyświetlana jest krótka informacja jaki pakiet należy zainstalować.
Od niedawna w Pingwinku pojawił się podobny i rozszerzony mechanizm. Pierwszą jego zaletą jest to, że nie potrzebuje dodatkowej bazy z możliwymi komendami do zainstalowania, ponieważ w pobranym indeksie ze zdalnego repozytorium jest informacja na temat listy plików. Drugą ważniejszą zaletą jest to, że box-not-found (tak to się nazywa) potrafi działać w kilku trybach: dowolny plik, komenda, manual, info, plik nagłówkowy albo pkgconfig. Dlaczego to jest fajne? Ponieważ wiem co zainstalować aby mieć danego mana. Kompilacja źródeł jest teraz bardzo prosta, bo w przypadku pliku nagłówkowego, czy pliku pkg-configa wiadomo co zainstalować! Przykład:
kaliber@localhost:~$ man flex No manual entry for flex Requested file 'flex' cannot be found, but you can simply install it! # file: /usr/share/man/man1/flex.1.gz sudo box -i flex
To, czego najbardziej brakowało w systemie pakietów box powoli staje się faktem. Mowa tu o systemowej bazie zawierającej informacje na temat zainstalowanych pakietów. Dzięki temu stało się możliwe ich odinstalowywanie. Również powstała możliwość instalowania pakietów ze zdalnych repozytoriów (tak jak np. w Debianie jest apt). Tak naprawdę pozostało jeszcze dużo do zrobienia - przetwarzanie zależności jest w bardzo początkowym w stanie dopiero. Od strony technicznej kod napisany jest w C z użyciem biblioteki glib. Wykorzystuję bazę sqlite3 do składowania danych. Zainteresowanych odsyłam do kodu w SVN http://svn.gna.org/viewcvs/pingwinek/trunk/box/ . Baza sprawuje się bardzo dobrze. Dla zainstalowanych ponad 2000 pakietów zajmuje 40MB. Faktyczny rozmiar byłby dwa razy mniejszy, ale spowodowane to jest indeksami w bazie. Przykładowo komeda szukająca zainstalowanego pliku, która zwraca 487 wyników trwa 0.5 sekundy: box-query -s README
Kolejnym krokiem ewolucji dystrybucji "Pingwinek GNU/Linux" jest automatyczne tworzenie pakietów przez automat (przez "robota"). Aktualnie robot skanuje RSS ze strony gnomefiles.org i dla nowych wpisów tworzy pakiety źródłowe box oraz próbuje je automatycznie budować. Czasami utworzony pakiet trzeba lekko poprawić, ale to jest z reguły kwestia jednej minuty, jeśli nie trzeba łatać źródeł. Dzięki temu prostemu zabiegowi repozytorium pakietów będzie rosło coraz szybciej.
Stworzyłem dystrybucję linuksa od zera która zawiera już prawie 2000 pakietów. Niedawno stwierdziłem, że chciałbym zrobić coś więcej, a dokładniej przeportować Pingwinka na inny system operacyjny. Pytanie tylko który wybrać? Jak wiadomo dystrybucji linuksa jest około 500, dystrybucji BSD jest już kilka a może kilkanaście nawet. W związku z tym postanowiłem zrobić coś czego jeszcze nie ma. I oto w ten sposób powstał Pingwinek GNU/Haiku. Co prawda początki są skromne bo przeportowałem tylko 40 pakietów. Problem w tym, że Haiku/BeOS nie używa X-serwera, dlatego praktycznie większość aplikacji graficznych nie ma. Dużym krokiem na przód byłoby przeportowanie Gtk+ na Haiku/BeOS. Może jest ktoś chętny do podjęcia tego wyzwania? W każdym bądź razie zapraszam do obejrzenia zrzutów ekranu z Haiku: http://home.gna.org/pingwinek/screenshots.html i ewentualnie do pobrania i uruchomienia.
Już od dawna frustrowała mnie sytuacja w której kolejne wersje źródeł czasami pojawiały się tylko jako archiwum tar.gz albo tar.bz2. Było to uciążliwe z dwóch powodów. Po pierwsze robot poszukujący nowych wersji pakietów poprzez FTP/HTTP nie był w stanie odnaleźć poprawnej wersji. Np. dla pakietu ed w wersji 0.2 użyte było archiwum w formacie tar.gz, natomiast kolejna wersja 0.3 występuje tylko jako tar.bz2. Po drugie podczas robienia pakietu źródłowego należało zmieniać adres do źródła na poprawny który z wersji na wersję mógł ulegać modyfikacjom pod kątem formatu archiwum.
Na szczęście od wczoraj taka sytuacja w systemie pakietów box nie ma prawa zaistnieć, ponieważ robot wykrywając nowe wersje bierze pod uwagę opisany powyżej problem oraz podczas robienia pakietu źródłowego odpowiedni plik zostanie ściągnięty.
W Pingwinku od dawna istnieje system automatycznego wykrywania nowych wersji pakietów. Polega to na tym, że robot okresowo skanuje serwery http oraz ftp w poszukiwaniu nowszych wersji pakietów źródłowych. Dotychczas identyfikacja wykonywana była tylko na podstawie adresu URL do źródeł. Co prawda jest to metoda bardzo skuteczna ale zawodzi w przypadku gdy katalog w którym znajduje się plik nie umożliwia przeglądania jego zawartości. Taka sytuacja nie jest częsta, ale występuje chociażby dla pakietów związanych z mono. Katalogu http://go-mono.com/sources/mono/ nie możemy przeglądać, dlatego system pakietów box doczekał się opcji <download>...</download> w której można podać stronę html na której znajdują się linki do najnowszych wersji. W opisywanym przypadku jest to http://go-mono.com/sources-stable/.
Skuteczność automatycznego wykrywania nowych wersji jest bardzo dobra. Na stan dzisiejszy ponad 37% pakietów zostało automatycznie choć raz uaktualnione do nowszej wersji. Więcej szczegółów (statystyk) można znaleźć na stronie http://home.gna.org/pingwinek/stats/packages.html.
W Pingwinku w systemie pakietów box od dawna istnieją automatyczne zależności tworzone podczas budowania paczki. Jedne z ciekawszych to zależności wykrywane poprzez śledzenie wyłołań pkg-configa. Np.
$ box -deps_build pango cairo fontconfig glib libxft
Wczoraj natomiast box dorobił się automatycznych zależności dla perla w oparciu o Module::ScanDeps. Teraz większym wyzwaniem pozostaje zaimplementowanie automatycznych zależności dla pythona.