Przenoszenie programów na modularne X

1.  Tło

Wstęp

Dlaczego jeden wygodny pakiet zmienił się w 300 mniejszych? Proces ten realizowany jest przez twórców X.Org. Rozdzielają oni wszystkie pakiety na pomniejsze, a my jedynie podążamy za nimi.

Polecamy lekturę Migracja na modularne X.

2.  Sprawdzanie zależności

Chcemy wyliczyć wszystkie zależności tak dobrze, jak to tylko możliwe, by użytkownicy nie musieli mieć w systemie zbędnych programów, których nawet nie używają (na przykład XPrint). Jeśli pakiet jest od czegoś zależny, to w zależnościach wpisujemy pakiety z bibliotekami i nagłówkami, a nie virtuale.

Nie możemy także zagwarantować, że użytkownicy wciąż będą mieli zainstalowane pewne zależności, ponieważ instalowali metapakiet, więc eliminacja tego typu błędu pozwoli zaoszczędzić nam dużo czasu.

Jeśli znajdę jakikolwiek pakiet, dla którego zależnością będzie metapakiet, będę prześladował osobę zajmującą się tym pakietem, dopóki tego nie naprawi.

Pierwszy krok, to zainstalowanie modularnego X lub odnalezienie kogoś, kto ma go zainstalowanego. Może to zostać wykonane w środowisku chroot - nie ma żadnego powodu, by uruchamiać X. Potrzeba jedynie, by pliki były dostępne podczas sprawdzania zależności.

$ wget http://dev.gentoo.org/~dberkholz/scripts/linking_libs.sh \
	http://dev.gentoo.org/~dberkholz/scripts/included_headers.sh \
	http://dev.gentoo.org/~betelgeuse/scripts/deputils/checkdeps.rb \
       	http://dev.gentoo.org/~betelgeuse/scripts/deputils/pkgutil.rb

Pierwszy skrypt, linking_libs.sh, sprawdza wyjście kompilacji danego pakietu poszukując wszystkich bibliotek połączonych z nim i wyświetla wszystkie pakiety, do których one należą. By uzyskać wyjście kompilatora, można ustawić zmienną PORT_LOGDIR w /etc/make.conf lub użyć przekierowania wyjścia.

$ ls /var/log/portage/*gdm* -l
-rw-r--r-- 1 root portage 556551 2006-01-09 11:41
/var/log/portage/8430-gdm-2.8.0.7.log 
-rw-r--r-- 1 root portage    855 2006-01-09 11:42
/var/log/portage/8431-gdm-2.8.0.7.log 
$ linking_libs.sh
/var/log/portage/8430-gdm-2.8.0.7.log

Drugi skrypt, included_headers.sh, przeszukuje rozpakowane źródła danego pakietu w poszukiwaniu linii, które zaczynają się od #include i sprawdza, jakie pliki zawierają się w <>. Na dzień 9 września 2005, tak jak <> działa również użycie "" w include.

Trzeci skrypt, checkdeps.rb, skanuje w poszukiwaniu zainstalowanych plików należących do pakietu, używając scanelf z pax-utils. Jest to praktyczne dla pakietów binarnych lub pakietów, które nie pokazują wyjścia kompilatora. Jest to skrypt pisany w języku Ruby więc wymaga on dev-lang/ruby, tak jak app-misc/pax-utils. Czwarty skrypt, pkgutil.rb, jest zależnością checkdeps.rb.

Uruchomienie dwóch powyższych skryptów powinno dać dobrą listę pakietów dla RDEPEND (dla bibliotek) i DEPEND (nagłówków i bibliotek). Jeśli biblioteka pokazuje na liście RDEPEND coś, co nie pojawiło się na liście DEPEND, należy być ostrożnym. Może to być "fałszywa zależność" (biblioteka, z którą pakiet jest związany bez żadnego powodu). Przykładem prawdziwej zależności jest libXt. Wiele pakietów szuka nagłówków libXt, w celu sprawdzenia występowania X w systemie.

Sporadycznie skrypt included_headers.sh znajdzie zły nagłówek, ponieważ niektóre z nich używają tej samej nazwy, a to powoduje, że skrypt zwróci nieprawidłowy pakiet. Zwykle takie pomyłki są oczywiste, tak jak w przypadku nagłówków Windowsa, przez które wydaje się, że app-emulation/wine jest zależnością.

Jeśli dopiszemy opcję -d, może to spowodować, że dostaniemy informację "Not found". Może to oznaczać, że odinstalowaliśmy nagłówek, który jest wymagany przez pakiet, by go zbudować lub jest to opcjonalny nagłówek, z którego nie korzystamy w naszym systemie. W przypadku biblioteki znaczyć to może, że odinstalowaliśmy bibliotekę, która została tylko statycznie zbudowana, ale nigdy nie została zainstalowana.

Warto poświęcić trochę czasu i zorientować się, które biblioteki lub nagłówki nie są dodawane do listy zależności. W przypadku nagłówków, nie trzeba mieć ich zainstalowanych, by przeprowadzić skanowanie.

W niektórych przypadkach, w pewnym sensie, pakiet wymaga serwera X. Jeśli nie jest to wymagane, by w czasie instalacji serwer X był obecny w systemie, odradzamy umieszczanie go na liście RDEPEND. Psuje to instalacje bez X, gdzie program jest uruchamiany na innym komputerze, więc nie wymaga istnienia nagłówków ani bibliotek na danej maszynie.

W drzewie portage znajduje się kilka serwerów X, więc jeśli nie potrzeba nam owego, należy dołączyć wszystkie. Modularne serwery X znajdują się w pakiecie xorg-server. Mamy również serwer DirectFB w pakiecie xdirectfb; kdrive jest małym serwerem X. Oczywiście mamy też do dyspozycji stare <xorg-x11-7. Należy również dołączyć restrykcje odnośnie wersji xorg-x11, by być pewnym, że mamy serwer X, zamiast metapakietu. W bliskiej przyszłości spodziewam się, że kdrive przeniesie się do serwera X. Jeśli potrzeba nam serwera X, należy skontaktować się z członkiem drużyny zajmującej się X. Możemy stworzyć virtual, jeśli wystarczająca liczba pakietów będzie tego wymagać

3.  Struktura zależności

By dodać zależności, będziemy potrzebowali następującej struktury:

RDEPEND="|| ( ( x11-libs/libXfoo
			x11-libs/libXbar
			blah? ( x11-libs/libXblah )
			cokolwiek innego pokaże skrypt od bibliotek
		)
		virtual/x11
	)

DEPEND="${RDEPEND}
	|| ( ( x11-proto/fooproto
			blah? ( x11-proto/blahproto )
			cokolwiek innego pokażą oba skrypty
		)
		virtual/x11
	)

Naszym celem jest nie tylko wparcie dla nowego, modularnego X, ale również umożliwienie spełnienie zależności użytkowników korzystających ze starego, monolitycznego X. By prawidłowo móc je spełnić, odrzucamy starą formę deklarowania virtual/x11.

Na początek przenoszenie aplikacji na nowy system jest jedynie wymagane dla użytkowników korzystających z niestabilnej gałęzi drzewa Portage (~arch) i nowszej (KEYWORDS=-* lub package.mask). Opiekunowie pojedynczych pakietów mogą wybierać, czy pozbyć się niewspieranych ebuildów z drzewa portage, ale najprawdopodobniej będą chcieli przenieść wszystkie swoje ebuildy naraz.

4.  Radzenie sobie z flagami USE

Wiele osób ma wyłączoną flagę xinerama. Jednakże, jeśli uruchomimy included_headers.sh, x11-proto/xineramaproto zostanie pokazane jako zależność. Dodajemy wówczas ten pakiet do DEPEND zasłonięte USE flagą xinerama i dodajemy x11-libs/libXinerama do RDEPEND, także z flagą xinerama.

Caleb zadał dobre pytanie: jak radzić sobie z flagami USE w pakietach, które mają ogromną ilość opcjonalnych bibliotek X? W wielu przypadkach ma sens wymuszanie włączenia lub też niewłączania flag. Można to sobie ułatwić, grupując flagi. Należy upewnić się, że nazwa flagi bierze się od funkcji jaką wprowadzają, a nie od nazw bibliotek czy też pakietów, z których będą korzystać.

5.  Wprowadzanie zmian do drzewa portage

Jeśli jesteśmy opiekunami lub twórcami pakietu, nadsyłamy nasze poprawki. Jeżeli nie, nadsyłamy poprawkę w formie błędu przydzielonego do opiekunów pakietu (można ich znaleźć w pliku metadata.xml). Dodajemy informację, że jest to błąd blokujący #112675. Załączamy łatę naprawiającą zależności.

Zawartość tego dokumentu jest rozpowszechniana na podstawie licencji Creative Commons - Attribution / Share Alike.