Niniejszym mogę z całym spokojem ogłosić oficjalne wydanie pierwszego jądra PLD/FreeBSD, kernel posiada numerek 6.3.0.0 i zamyka pewien etap tego projektu. Z wydaniem tego jądra wiąże się bowiem to, że do przebudowania całości nie bedzie już nigdy potrzebny FreeBSD (na którym do tej pory było produkowane jądro dla PLD/FreeBSD).

Z ciekawostek, jako że nikt mi nigdy nie powiedział, że do budowania jądra nie da się zaprząc autoconfa i automake'a. I z drugiej strony, z braku pomysłu na szybkie w implementacji narzędzie do budowania tegoż, spróbowałem użyć do tego celu właśnie autotoolsy… I udało się. Pomijam, że regeneracja plików configure i wszystkich Makefile'ów trwa dłuzej niż samo budowanie kernela, kto by sie tym przejmował.

Teraz, kolejny duży krok to będzie instalator… ale kiedy?

Znalazłem winnego. Byłem prawie pewien, że to był aniou, ale wydawało mi się że to było rok albo dwa wcześniej. W każdym razie taka jest geneza PLD/FreeBSD.

Ponieważ zgłosiło się do mnie już kilka osób z pytaniem jak można zainstalować PLD/FreeBSD postanowiłem coś z tym zrobić. Na początek PLD/FreeBSD Preview 1 w postaci spakowanej maszyny wirtualnej do VMWare Workstation. Do pobrania tutaj (41.5 MB). System minimalny jak tylko się dało, więc można sobie popoldkować.

Po uruchomieniu maszyny i zalogowaniu się na roota (hasło puste) trzeba skonfigurować sieć:

ifconfig lnc0 192.168.1.2
route add default 192.168.1.1
echo "nameserver 192.168.1.1" > /etc/resolv.conf

albo wyedytować znane z PLD pliki odpowiedzialne za powyższe i zrestartować usługę network

/etc/rc.d/init.d/network restart

I już można działać. Nie polecam instalowania pakietu kernel i loader bo te które są na FTPie mogą kompletnie rozwalić system.

Zainteresowanym życzę miłej zabawy.

Jak tylko znajdę chwilę czasu postaram się opisać jak zainstalować PLD/FreeBSD na fizycznej maszynie przy pomocy płyty instalacyjnej FreeBSD.

Po raz trzeci zabrałem się za pisanie builderów dla PLD/FreeBSD. Efekt jest taki, że podstawowe funkcjonalności są już gotowe, a w czasie kiedy na nowych builderach testowo przebudowywane są wszystkie pakiety spłodziłem krótki tekst opisujacy ich działanie. Zainteresowanych zapraszam do lektury.

W gruncie rzeczy tekst ma być o tym dlaczego SVN jest lepszym wyborem w przypadku repozytorium pakietów. Swoje przemyślenia opieram na bez mała trzy i pół rocznym doświadczeniu z repozytorium http://svn.pld-freebsd.org/svn/packages, dostepnym równiez przez ViewCVS: http://svn.pld-freebsd.org/cgi-bin/viewsvn/.

Struktura repozytorium różni sie znacząco od płaskiego modelu repozytorium stosowanego w PLD. W dużym uproszczeniu wygląda ona tak:

packages
 +- trunk
 |    +- db
 |    |    +- SOURCES
 |    |    |    +- patch1.patch
 |    |    |    +- patch2.patch
 |    |    +- SPECS
 |    |         +- db.spec
 |    +- rpm
 |         +- SOURCES
 |         |    +- patch1.patch
 |         |    +- patch2.patch
 |         +- SPECS
 |              +- rpm.spec
 +- branches
 |    +- rpm-4.1.1
 |    |    +- db
 |    |    |    +- SOURCES
 |    |    |    |    +- patch1.patch
 |    |    |    |    +- patch2.patch
 |    |    |    +- SPECS
 |    |    |         +- db.spec
 |    |    +- rpm
 |    |         +- SOURCES
 |    |         |    +- patch1.patch
 |    |         |    +- patch2.patch
 |    |         +- SPECS
 |    |              +- rpm.spec
 |    +- rpm-4.4.1
 |         +- db
 |         |    +- SOURCES
 |         |    |    +- patch1.patch
 |         |    |    +- patch2.patch
 |         |    +- SPECS
 |         |         +- rpm.spec
 |         +- rpm
 |              +- SOURCES
 |              |    +- patch1.patch
 |              |    +- patch2.patch
 |              +- SPECS
 |                   +- rpm.spec
 +- tags
      +- Ac-rpm-4.4.1-2
           +- db
           |    +- SOURCES
           |    |    +- patch1.patch
           |    |    +- patch2.patch
           |    +- SPECS
           |         +- rpm.spec
           +- rpm
                +- SOURCES
                |    +- patch1.patch
                |    +- patch2.patch
                +- SPECS
                     +- rpm.spec

Jak widać na powyższym schemacie dla każdego pakietu została wydzielona osobna gałąź w drzewie repozytorium. Taki zabieg, poza uporzadkowaniem i separacją składników poszczególnych pakietów, pozwala na rozdzielenie przestrzeni nazw plików w pakietach. A co za tym idzie, powoduje że np. nazwa patcha może być dowolna dla zadanego pakietu i nie istnieje konieczność pilnowania żeby nazwy łatek dla różnych pakietów nie kolidowały ze sobą. W szczególności, nie ma potrzeby narzucania nazewnictwa tych łatek do postaci nazwa_pakietu-nazwa_łatki.patch jak ma to miejsce w PLD.

Ściagnięcie całego drzewa trunk może wygląda nastepująco:

svn checkout http://svn.pld-freebsd.org/svn/packages/trunk packages

Natomiast ściagniecie i kompilacja pakietu db z takiego repozytorium wygląda tak:

$ cd ~/packages
$ svn checkout http://svn.pld-freebsd.org/svn/packages/trunk/db
$ cd db/SPECS
$ rpmbuild -ba --define "_topdir ~/packages/db" db.spec

Powyższy przykład nie uwzględnia oczywiście ściagnięcia ewentualnych tarballi z distfiles.

Drzewiastej strukturze repozytorium można zarzucać niemozliwość "przegrepowania" wszystkich specy, albo wprowadzania masowych zmian w specach. Wadę tą można wyeliminować używając polecenia find. I tak odpowiednikiem grep jakisstring * w katalogu SPECS jest

find . -name "*.spec" -exec grep -H jakisstring {} \;

w katalogu packages/trunk.

Praca z takim repozytorium nie jest dużo bardziej skomplikowana, niż z płaskim repozytorium CVSowym. A prawie zupełnie nie różni się gdy użyjemy odpowiednio zmodyfikowanego skryptu builder.

Kolejną przewagą nad CVSem są "atomowe" commity. Polega to na tym, że po wprowadzeniu zmian z pakiecie, zmiany są przekazywane do repozytorium jednym poleceniem, np.

$ cd ~/packages
$ svn commit -m "- updated to 4.5\n- updated patch1 patch" db

Co najważniejsze, takie dokonanie zmiany jest traktowane w repozytorium jako integralna całość identyfikowana numerem rewizji w repozytorium, a nie jest złożeniem zmian w poszczególnych plikach. Co za tym idzie możemy łatwo odszukać, że np. update db do wersji 4.5 pociągneło za sobą usuniecie pliku SOURCES/patch1.patch. W CVSie, niestety, każda tego typu zmiana jest w repozytorium traktowana osobno, dlatego dużo wiecej pracy kosztuje odnalezienie jak zmieniły się pozostałe pliki pakietu, podczas określonej zmiany pliku spec. Takie zachowanie CVSa jest dla mnie szczególnie uciążliwe, ponieważ w swojej pracy intensywnie śledzę zmiany w repozytorium PLD w celu nanoszenia niektórych z nich w PLD/FreeBSD.

Atomowość commitów w repozytorium pociaga za sobą również zwiekszenie przejrzystości commitlogów, dzięki temu są one generowane jako pojedynczy mail, a nie dwa osobne maile zawierajace zmiany odpowiednio, w module SPECS i w module SOURCES.

Kolejna przewagą Subversion jest możliwość przenoszenia plików (z zachowaniem historii zmian) z poziomu użytkownika. W CVSie taka operacja wymaga zaangażowania administratora repozytorium, który musi dokonać takiej zmiany po stronie serwera.

Dla niektórych kolejną wadą SVNa może być niemożliwość generowania sekcji %changelog, tak jak ma to miejsce w chwili obecnej w PLD. Według mnie używanie $Log$ do generowania loga to średnio dobry pomysł, tym bardziej, że taki log nie jest tworzony w formacie przyjmowanym przez RPMa. Słuszniej byłoby gdyby %changelog był generowany z loga SVNa na source-builderach w formacie natywnym dla RPMa.

Na koniec wypada jeszcze wspomnieć o łatwości instalacji serwera Subversion. Po raz pierwszy zajeło mi to kilkanaście minut, podczas gdy na instalację serwera CVSu straciłem kilka(naście) godzin.