Sprzątanie w Debianie, czyli jak usunąć stare pakiety.

Debian to system, który – na podstawie założeń twórców i moich doświadczeń – bez problemu można zaktualizować do kolejnej wersji. Jednak – jak pokazuje praktyka – nie zawsze zostaną przy tym usunięte wszystkie zbędne pakiety. Szczególnie, jeśli korzystamy z dodatkowych, nieoficjalnych repozytoriów. Poniżej quick’n’dirty sposób na półautomatyczne znalezienie i usunięcie pakietów, które nie mają już kandydata do instalacji z repozytorium.

Dziś siadłem na chwilę do starego desktopa, na którym działa Lenny. Taki pochodzący z upgrade od Sarge, przez Etch i parę wersji testowych, na dodatek nie wg release notes. Stwierdziłem (po odpaleniu mp3 z netu, które uruchomiło się w beep media player), że są jakieś stare pakiety typu proftpd-common, a miejsce na / się kończy. Pakiety stare, czyli takie z Sarge/Etch. Postanowiłem zrobić porządek. Szybki gógiel nie dał rozwiązania, a przyszedł mi do głowy prosty algorytm, więc stanęło na DIY.

Wyświetlenie pakietów, które są zainstalowane (lub ich pliki konfiguracyjne), a które nie są z Lenny’ego. Dodatkowo zapisujemy wynik do 2delete.txt w celu dalszej obróbki.

dpkg -l | awk '{print $2}' | perl -ne 'chomp; $res=`wajig policy $_ | \
grep lenny`; print $_,$/ if $?' | tee 2delete.txt

Założenie jest takie, że w /etc/apt/sources.list wszystkie wpisy odnoszą się do lenny. Jeśli mamy także stable, to należy zmienić grep lenny na egrep „lenny|stable”. Przed zrobieniem czegoś więcej należy przejrzeć listę w 2delete.txt i usunąć wrażliwe pakiety. Oraz te, które chcemy zatrzymać, mając na uwadze fakt, że powyższe polecenie wyświetli także pakiety zainstalowane ręcznie, np. własny kernel.

Jak już jesteśmy pewni, że wiemy co robimy (w przypadku usunięcia zbyt wielu pakietów możemy ładnie i łatwo zepsuć system do takiego stopnia, że bez liveCD nie przywrócimy go do działania) i że w pliku 2delete.txt nie ma jakichś jednak potrzebnych pakietów, to możemy spróbować automatycznie usunąć pakiety z listy (po jednym):

cat 2delete.txt | xargs wajig purge

Wynikowi powyższego warto się przyjrzeć, w szczególności błędom podczas przetwarzania. W moim przypadku wynikały one z zależności pomiędzy usuwanymi bibliotekami. Jednak wywołanie ich razem, w jednym poleceniu wajig purge rozwiązało problem.

Na koniec możemy zobaczyć, czy pojawiły się jakieś „sierotki” czyli wydajemy polecenie deborphan lub orphaner. Po usunięciu sierotek możemy spróbować wywołać dla pewności nasz pierwszy skrypt. A następnie zrestartować system (czyli tzw. chwila prawdy, czy się nie pomyliliśmy). U mnie działa.

Virtualbox i własny kernel

Krótkie howto jak w Debianie Lenny korzystać z własnego kernela (tu: 2.6.30.5) i Virtualbox.

W związku z remasteringiem Knoppiksa na potrzeby Anonymiksa zainteresowałem się bliżej rozwiązaniami do wirtualizacji. Kiedyś (3 lata temu?) korzystałem z VMware Playera, który idealny nie był. Trochę za sprawą licencji, trochę za sprawą tego, że nie do końca pozwalał na tworzenie własnych obrazów. IIRC dało się je zrobić, z użyciem qemu. Także bootowaniem z CD było trzeba powalczyć. Z kolei remastering Knoppiksa na fizycznej maszynie jest jak najbardziej wykonalny, ale niewygodny – rebooty, uruchamianie Knoppiksa itd. Aż się prosi o wirtualizację.

Sporo dobrego słyszałem ostatnio o Virtualbox. Niestety, wersja w Debianie zrobiona jest pod konkretny kernel. Ponieważ znajomi korzystają, postanowiłem się zapytać, w jaki sposób. Okazuje się, że nie korzystają z wersji dystrybucyjnej, a z wersji bezpośrednio od producenta, czyli przez dodanie

deb http://download.virtualbox.org/virtualbox/debian lenny non-free

do /etc/apt/sources.list, a następnie apt-get install virtualbox-3.0. Tyle, że także korzystają z dystrybucyjnego kernela. Co mnie szczerze mówiąc zdziwiło, bo lapek i dystrybucyjny kernel jakoś mi ze sobą nie pasują (nie żeby nie działało, bo działa). Albo ja po prostu jestem dziwny i lubię mieć nowe i na miarę (I, ricer), albo jeszcze mam czas na takie zabawy. 😉

W każdym razie korzystanie z dystrybucyjnego kernela wydało mi się nieporozumieniem. Niemal takim nieporozumieniem, jak praca na fizycznej maszynie i rebooty (tak, wiem, przesadzam). FAQ na stronie i dokumentacja na pierwszy rzut oka nie przewidują takiej możliwości. Poszukałem więc rozwiązania ma własną rękę (pomoc na IRC jest przereklamowana). Nie pamiętam słów kluczowych do wyszukiwarki, ale ostatecznie trafiłem na ten wpis (dead link). Rozwiązanie jest – jak widać – bardzo proste.

Dla porządku, dla niespikających: należy pobrać paczkę .deb właściwą dla naszego systemu ze strony producenta i zainstalować ją (apt-get install pakiet.deb). Podczas instalacji, wykryty zostanie brak modułu i zostaniemy zapytani, czy chcemy zbudować tenże moduł dla aktualnie działającego kernela. Wymagane są oczywiście źródła (headers?) w /usr/src i narzędzia do kompilacji kernela. Zakładam, że jak ktoś ma custom kernel, to wie, co potrzebne. Wadą rozwiązania jest konieczność pamiętania o dpkg-reconfigure virtualbox po każdej zmianie kernela w celu zbudowania modułu dla nowej wersji. Dla 2.6.30.5 działa bez problemu.

Iceweasel 3.5 w Lenny (failed).

W związku z tym, że Mozilla zaleca przejście na wersję 3.5 Firefoksa, postanowiłem sprawdzić, na ile skomplikowana będzie instalacja tej wersji w Lennym. Dla niecierpliwych od razu informacja – nie udało się, a opis całości – poniżej.

Ku mojemu zdumieniu Iceweasel zarówno w testing, jak i sid jest w wersji 3.0.x, a wersja 3.5 dostępna jest dopiero w experimental. Na blogu developera w komentarzach są doniesienia, że udało się na Lennym i działa OK, więc – czemu nie?

Stwierdziłem, będę się trzymał wersji z oficjalnych repozytoriów, czyli pobiorę źródła iceweasel i xulrunner-1.9.1.1 z experimental i zrobię backport (czyli tradycyjnie). Przy okazji drobne posiłkowanie się pakietami z testing/sid, głównie do spełnienia zależności do budowy (na pewno libnspr4-0d, libnspr4-dev, libsqlite3-dev, libsqlite3-0). Źródła xulrunner-1.9.1.1 plus zależności do ich budowy to ponad 100 MB, ale mamy miejsce, mamy czas… Niestety, pod koniec kilkudziesięciominutowej kompilacji w którymś z plików cpp pojawiły się błędy i xulrunner-1.9.1.1 się nie zbudował.

Prawie dałem za wygraną, gdy dostałem wiadomość, że wystarczy apt-get -t experimental iceweasel. No niezupełnie, gdyż iceweasel: Wymaga: xulrunner-1.9.1 ale nie zostanie zainstalowany. Jednak zachęciło mnie to do dalszego działania – skoro dobrzy ludzie twierdzą, że się da, to pewnie się da. 😉

Po bliższym przyjrzeniu okazało się, że wystarczy doinstalować libasound2 libhunspell-1.2-0 libnss3-1d oraz libstartup-notification0 w wersji z testing. Pierwsze trzy poszły gładko. Zadziwiająco gładko. Za to ostatni zażyczył sobie także libxcb-aux0, libxcb1 w wersji z testing.

Na próbę ich (właściwie libxcb1) instalacji system zareagował dość żywiołowo, bo Po tej operacji zostanie zwolnione 1534MB miejsca na dysku, przy czym w grę wchodziło praktycznie całe xorg, openoffice, icedove, iceweasel

Stwierdziłem, że nie ma sensu tak sobie rozgrzebywać systemu na noc, lepiej obejrzeć film… Chyba jednak stable średnio się nadaje na tego laptopa, jeśli chce się korzystać tylko z wolnego softu i na dodatek z nowych. Z fglrx jakoś miałem stable (plus trochę backportów własnej produkcji) przez ostatnie dwa lata, ale teraz po prostu zrobię w chwili wolnej upgrade do testing/sid. Będzie nowy xorg, działające 3D, łatwiejsze dodawanie nowych wersji, KDE 4.3… Z drugiej strony stable po prostu działa, a iceweasel chociaż 3.0.x, to połatany (ciekawe jak długo…).

P.S. Tak, wiem, mogę doinstalować wersję Firefoksa bezpośrednio od Mozilli. Nie wykluczam, że tak zrobię.