Portage - wyświetlanie informacji o zmianach

Dzisiaj krótko. Portage wśród swoich możliwości ma śledzenie zmian wprowadzanych między kolejnymi wydaniami dowolnego pakietu - tzw. changelogi. Jeśli chcemy być na bieżąco - to oprócz widocznych zmian we flagach (opcja --verbose) - możemy wyświetlić informacje o zmianach w funkcjonalności pakietu. Wśród licznych opcji narzędzia emerge mamy przełącznik --changelog (-l). Zaprezentuję to na przykładzie pakietu apache:

emerge -p --changelog apache

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild U ] www-servers/apache-2.2.11-r2 [2.2.11]

*apache-2.2.11-r2

07 Jul 2009; Benedikt Böhm +apache-2.2.11-r2.ebuild:
fix #276707, #276792

07 Jul 2009; Richard Freeman apache-2.2.11-r1.ebuild:
amd64 stable - 276589

06 Jul 2009; Brent Baude apache-2.2.11-r1.ebuild:
Marking apache-2.2.11-r1 ppc64 and ppc for bug 276589

06 Jul 2009; Jeroen Roovers apache-2.2.11-r1.ebuild:
Stable for HPPA (bug #276589).

*apache-2.2.11-r1

05 Jul 2009; Benedikt Böhm -apache-2.2.9-r1.ebuild,
+apache-2.2.11-r1.ebuild:
fix #263588, #265547, #231913, #268154, #271470, #272951, #276426

02 May 2009; Jeroen Roovers apache-2.2.11.ebuild:
Stable for HPPA (bug #265705).

26 Apr 2009; Raúl Porcel apache-2.2.11.ebuild:
arm/ia64/s390/sh/sparc stable wrt #265705

26 Apr 2009; Brent Baude apache-2.2.11.ebuild:
Marking apache-2.2.11 ppc for bug 265705

23 Apr 2009; Markus Meier apache-2.2.11:
amd64/x86 stable, bug #265705

23 Apr 2009; Tobias Klausmann apache-2.2.11:
Stable on alpha, bug #265705

21 Apr 2009; Brent Baude apache-2.2.11.ebuild:
Marking apache-2.2.11 ppc64 for bug 265705

23 Jan 2009; Raúl Porcel apache-2.2.10.ebuild:
alpha/arm/ia64/s390/sh stable wrt #252432

09 Jan 2009; Brent Baude apache-2.2.10.ebuild:
Marking apache-2.2.10 ppc for bug 252432

07 Jan 2009; Brent Baude apache-2.2.10.ebuild:
Marking apache-2.2.10 ppc64 for bug 253432

04 Jan 2009; Markus Meier apache-2.2.10.ebuild:
amd64/x86 stable, bug #252432

04 Jan 2009; Friedrich Oslage apache-2.2.10.ebuild:
Stable on sparc, bug #252432

01 Jan 2009; Guy Martin apache-2.2.10.ebuild:
hppa stable, #252432

Jak widać emerge wyświeli nam wszystkie zmiany jakie zaszły pomiędzy aktualnie zainstalowaną wersją pakietu (2.2.11) a najnowszą, zalecaną do instalacji.

To tyle. Polecam w wolnym czasie samodzielne poszukiwania w man emerge.

Daniel Robbins o Gentoo, zarządzaniu pakietami

W wolnym czasie polecam wywiad z Danielem Robbinsem - twórcą dystrybucji Gentoo. Ciekawie o Portage'u jak o przepisie na instalację - bardzo trafne spostrzeżenie.

Zarządzanie stacjami Windows za pomocą Cygwina, cz. I - Instalacja Cygwina i przygotowanie paczki do cichej instalacji

Cytat dnia:
The two basic principles of Windows system administration:

* For minor problems, reboot
* For major problems, reinstall

Ta idea przyświeca zapewne większości administratorów Windows (są oczywiście nieliczne wyjątki ale ja w swojej karierze takich nie spotkałem).
To będzie prawdopodobnie pierwszy z cyklu artykułów na temat zdalnego zarządzania stacjami Windows.
Od dłuższego czasu próbuję znaleźć rozsądny sposób na zarządzanie stacjami będącymi w domenie ale zarządzanymi przez serwer Linuksowy z działającą Sambą. Co to jest Samba? O tym opowiem z pewnością w przyszłości...
A teraz zajmijmy się zarządzaniem stacjami Windows.
Po dłuższym rozeznaniu tematu znalazłem pewien zestaw aplikacji open source wspomagających zarządzanie stacjami roboczymi. Pozwolę sobie je tu wymienić:
- projekt unattended-gui - umożliwia zarządzanie infrastrukturą, na pierwszy rzut oka niby wiele można (zarządzanie oprogramowaniem na stacjach windows, linux, konfiguracją sieci, switch'y, etc.) jednak nie znalazłem zbyt wielu informacji jak to się dokładnie robi. Możliwe jednak, że się mylę - na swoje usprawiedliwienie dodam, że przeglądałem to jedynie przez parę minut - projekt mnie nie przekonał, na tyle, żeby z niego skorzystać. Jednak na pewno będę miał go na oku.

- projekt kontrolpack - dostęp do zdalnej konsoli systemów Windows, Linux, Mac OS X. Działa w architekturze klient-serwer. Dosyć ciekawe rozwiązanie, jednak chyba jeszcze nie w pełni dopracowane. W trakcie testów doświadczyłem pewnych problemów ze zwieszaniem się klienta windowsowego przy odpalaniu skryptów Ruby. Wydaje się, że przy dużej liczbie stacji udostępnienie konsoli może być niewystarczającym rozwiązaniem. Nie znalazłem żadnych informacji na temat tworzenia grup hostów. Klient łączy się z serwerem na dziwnym porcie - wygląda na to, że korzysta z własnego protokołu transmisji - co mnie nie przekonuje - tym bardziej, że nigdzie w dokumentacji nie znalazłem informacji na temat sposobu wymianych danych między klientem a serwerem, a cóż tu dopiero mówić o jej bezpieczeństwie. Projekt rozwija się dynamicznie i miejmy nadzieję, że w krótkim czasie funkcjonalność i dokumentacja znacznie się poprawią.

- winexe - znalazłem gdzieś na forum, program umożliwiający zdalne podłączenie do stacji i uruchomienie dowolnego procesu. Pozwolę sobie w dalszym cyklu artykułów napisać o nim więcej.

- cygwin - nazwijmy go emulatorem środowiska Linux na windowsie. Dokładny opis można znaleźć w wikipedii

Poza programi open source warto wspomnieć o dwóch opcjach komercyjnych:
- program psexec - zdalne wykonywanie poleceń - podobnie jak winexe
- windows services for unix - odpowiednik cygwina stworzony przez Microsoft - ciężka kobyła (300MB) a nie ma nawet w pakiecie usługi ssh. Według Microsoftu ma przekonać administratorów *nix do środowiska windows i ułatwić ich migrację na nową platformę. Jednak w środowisku administratorów *nix program nazywany jest przewrotnie unix services for windows - krótko mówiąc brakująca proteza umożliwiająca w miarę rozsądną pracę w środowisku windows.
SFU po zainstalowaniu umożliwia połączenie ze stacją za pomocą protokołu telnet (przypominają się dawne czasy). Co prawda chłopaki coś wspominają o tym, że jest problem z przesyłaniem haseł plain tekstem przez sieć, ale przecież instalujemy to w zaufanej infrastrukturze - więc w czym rzecz? No jeśli już potrzebujecie to instalujcie openSSH - ale jak? To poszukajcie w sieci - mi się odechciało.

Po dłuższej analizie i licznych próbach (współ)pracy z powyższymi narzędziami dokonałem wyboru - tandem:
Cygwin, winexe i Ruby (jako język skryptowy) powinien zaspokoić moje potrzeby/wydumane wymagania.

Teraz po krótce pozwolę sobie opisać na początek kolejne kroki instalacji i przygotowywania pakietu Cygwin do używania w zarządzaniu stacjami Windows.

Pojawia się tu kilka niuansów nad którymi spędziłem trochę czasu, szczególnie wredny jest etap przygotowywania cichej instalacji i sama cicha instalacja.

Ze strony głównej projektu Cygwin ściągamy instalkę setup.exe.

Lista dostępnych opcji instalatora:
-D --download Download from internet
-L --local-install Install from local directory
-s --site Download site
-R --root Root installation directory
-q --quiet-mode Unattended setup mode
-h --help print help
-l --local-package-dir Local package directory
-r --no-replaceonreboot Disable replacing in-use files on next
reboot.
-n --no-shortcuts Disable creation of desktop and start
menu shortcuts
-N --no-startmenu Disable creation of start menu shortcut
-d --no-desktop Disable creation of desktop shortcut
-A --disable-buggy-antivirus Disable known or suspected buggy anti
virus software packages during
execution.

*Przygotowanie paczki cygwin do cichej instalacji na wielu stacjach roboczych
- Uruchamiamy setup.exe
- wybieramy katalog docelowy (c:\cygwin)
- wybieramy lokalny katalog repozytorium pakietów (c:\cygwin-root\root-dir) - należy go stworzyć przed instalacją
- wybieramy instalację z sieci
- wybieramy mirror (w sumie dowolny)
- wybieramy dodatkowe paczki do zainstalowania (z bardziej przydatnych: openssh, wget, procps, linux-utils, netcat)
- przechodzimy przez kolejne kroki instalatora

Po zainstalowaniu cygwina w katalogu z repozytoriami (c:\cygwin-root\root-dir) pojawi się folder, którego nazwa będzie adresem serwera źródeł instalacji (mirror) wybranego w trakcie uruchomienia instalatora cygwin.
Sam cygwin zainstaluje się w c:\cygwin.
Musimy teraz odtworzyć strukturę z konfiguracją zainstalowanego cygwina w katalogu c:\cygwin-root:
- tworzymy katalog c:\cygwin-root\cygwin\etc\setup
- przegrywamy z c:\cygwin\etc\setup do katalogu c:\cygwin-root\cygwin\etc\setup wszystkie pliki, których nazwa zaczyna się od last- (last-*)
- kopiujemy z c:\cygwin\etc\setup do c:\cygwin-root\cygwin\etc\setup plik setup.ini

Mamy już gotową konfigurację, którą możemy posłużyć się przy kolejnych instalacjach cygwina na stacjach roboczych.

*Cicha instalacja paczki cygwin na stacji roboczej
- tworzymy katalog c:\cygwin
- kopiujemy katalog c:\cygwin-root\cygwin\etc do c:\cygwin
- uruchamiamy instalator w trybie cichej instalacji:

setup.exe -q -R c:\cygwin -L -l c:\cygwin-root\root-dir

Jeżeli chcemy mieć Cygwin'a zainstalowanego na dysky systemowym zamiast identyfikatora napędu (c:) warto użyć zmiennej systemowej %systemdrive%

*Uruchomienie usługi SSH na stacji
Rejestracja SVC
- uruchamiamy konsolę cygwina
- uruchamiamy polecenie ssh-host-config
- odpowiadamy na zadawane pytania:
"privilege separation" => yes
"create local user sshd" => yes
"install sshd as a service" => yes
"CYGWIN=" => ntsec tty
- jeżeli pojawią się błędy - należy poprawić ustawienia systemu zgodnie z zaleceniami, które wyświetli ssh-host-config
- uruchamiamy utworzony serwis sshd za pomocą jednej z dwóch komend

net start sshd
cygrunsrv --start sshd

Teraz trzeba jeszcze odblokować usługę na firewall'u:

cmd /c if exist c:\windows\system32\netsh.exe netsh firewall set allowedprogram c:\cygwin\usr\sbin\sshd.exe SSHD enable

Muszę przyznać, że zarządzanie firewallem Windowsowym jest bardzo podobne do tworzenia reguł za pomocą iptables (o ile nie robimy tego w GUI ;)), a więc bardzo wygodne - ale o tym to już innym razem.

WAŻNE!
*Żeby użytkownicy Windows mogli się logować należy synchronizować bazy danych użytkowników w Windowsie ze środowiskiem Cygwin. Robimy to za pomocą:

mkpasswd -cl > /etc/passwd
mkgroup --local > /etc/group

*Zawsze upewnij się, że każdy użytkownik w systemie ma ustawione hasło do logowania.

Przydatne linki:
Projekt Cygwin
Cygwin FAQ
Z jakiegoś forum na temat instalacji Cygwina

Sudo - nadawanie specjalnych uprawnień

Ponieważ nie zamierzam przepisywać, podam link do dobrego przewodnika po komendzie sudo. O dziwo jest taki przewodnik zrobiony przez Gentoo. To kolejna zaleta tego projektu - świetna, dogłębna i spójna dokumentacja.

Po zaznajomieniu się z komendą czas na praktykę.
Ja w swoim zastosowaniu, w stawianym systemie chcę nadać możliwość instalowania pakietów za pomocą polecenia emerge jednemu użytkownikowi. Jak to zrobić?
Proponuję tak:

# visudo
-bash: visudo: command not found

O cholewcia - nie jest zainstalowane. Więc poszukajmy w portage'u:

emerge --search sudo

W czasie kiedy to polecenie się wykonuje dopiszę kolejną według mnie (niewielką) zaletę Gentoo -w porównianiu do dystrybucji debianowych jedną komendą zainstalujemy, wyszukamy pakiet - w Debianie są osobne i nieintuicyjne apt-get (instalacja) apt-cache search(bodajże - wyszukiwanie).
Dobra - mam już wyniki - a wśród nich:

Searching...
[ Results for search key : sudo ]
[ Applications found : 6 ]

* app-admin/sudo
Latest version available: 1.7.1-r1
Latest version installed: [ Not Installed ]
Size of files: 738 kB
Homepage: http://www.sudo.ws/
Description: Allows users or groups to run commands as other users
License: as-is BSD

Ponieważ emerge --search wyszukuje pakiet przeglądając na bieżąco wszystkie ebuildy w portage'u (/usr/portage - chyba wszystkie - tak mi się wydaje - a jeśli nie to metadata) nieraz możemy się poirytować czasem trwania wyszukiwania - jak to miało miejsce w moim wypadku. Proponuję używać komendy eix. hmm.. pryska zaleta jednej komendy do wyszukiwania i instalacji - no cóż - ale za to mamy szybko działającego eix'a - apt-chache strasznie muli mimo, że podobnie jak eix wyszukuje dane we własnej, zindeksowanej wcześniej bazie pakietów.
eix instaluję tak (warto zainstalować z bazą sqlite - odpowiednia flaga jest przy pakiecie):

# emerge -av eix

Zalecam używanie opcji --verbose --ask przy każdej instalacji - zawsze warto mieć wgląd w to co się będzie działo niż na ślepo instalować.

Zainstaluję w końcu sudo:

# emerge -av sudo
These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] app-admin/sudo-1.7.1-r1 USE="pam -ldap -offensive (-selinux) -skey" 739 kB

Total: 1 package (1 new), Size of downloads: 739 kB

Would you like to merge these packages? [Yes/No]

I już. Teraz nadaję uprawnienia użytkownikowi:

# visudo

Dodaję linię:
user localhost = /usr/bin/emerge

i już - użytkownik user może używać komendy emerge.

Instalacja pakietów w dystrybucji gentoo na przykładzie serwera subversion. Część II

Ostatnio zakończyłem na sprawdzeniu znaczenia USE-flag za pomocą komendy euse. Pora powiedzieć trochę więcej o tych flagach.
Większość pakietów (programów) dostępnych w dystrybucjach Linuksa rozprowadzanych jest na licencji GPL lub BSD (są też rzadziej używane LGPL, MIT, etc.), co oznacza, że źródła tych programów dostępne są w sieci bezpłatnie. Autor udostępnia swoją pracę - umożliwiając nam jednocześnie wprowadzanie w niej zmian na określonych licencją warunkach. Co to oznacza w praktyce?
Na przykład to, że możemy taki pakiet ściągnąć i zainstalować na swoim komputerze za darmo. Ponieważ są to jednak wyłącznie źródła, a nie gotowy do uruchomienia program, konieczna jest ich kompilacja do wersji binarnej. Każdy dobrze przygotowany pakiet źródłowy zawiera pliki INSTALL i README, w których autor opisuje sposób instalacji. Najczęściej są to trzy kroki:
- konfiguracja pakietu (./configure) z odpowiednimi opcjami
- kompilacja - make
- instalacja - make install

W wypadku wielu pakietów oprogramowania - szczególnie tych bardziej zaawansowanych - np. subversion'a pierwszy krok (konfiguracja) może przysporzyć sporego bólu głowy. Musimy określić wiele ustawień dotyczących instalowanego pakietu, m.in.:
- gdzie ma być zainstalowany (domyślnie jest to zazwyczaj /usr/local)
- czy stworzyć biblioteki umożliwiające obsługę subversion z poziomu języka ruby, python, perl, java?
- czy skompilować z dodatkowymi modułami?
- czy skompilować moduły umożliwiające współpracę z repozytorium za pośrednictwem apache'a?
- czy dodać bibliotekę odpowiedzialną za obsługę repozytoriów za pomocą protokołu http?

Szczegółowe możliwości konfiguracji pojedynczego pakietu można sprawdzić po rozpakowaniu paczki źródłowej i uruchomieniu programu ./configure --help

Można oczywiście skorzystać z gotowych pakietów dostarczanych przez główne dystrybucje Linuksa. Co jednak zrobić gdy chcemy mieć dodatkową funkcjonalność, która przez dystrybucję nie została dodana do standardowego modułu, hmmm... Weźmy przykład przeglądarki tekstowej links. Standardowo dostarczana jest ona bez obsługi protokołu ssl (dziwne, nieprawdaż?). Co sie wtedy robi, ano przecież jest to oczywiste - odinstalowuje pakiet links i instaluje pakiet links-ssl. Ciemność widzę... No tak i tu zaczyna się opisywane już wcześniej pojęcie 'packaging hell'. Tysiące zależności, miliony pakietów, które tak naprawdę są tym samym pakietem, tylko z inną funkcjonalnością.
I tu z pomocą przychodzi nam rozwiązanie oferowane przez portage. Jeden pakiet, w którym to my definujemy jaką ma on mieć funkcjonalność. Robimy to właśnie za pomocą USE-flag. Weźmy nieszczęsny pakiet links - wiemy już jak dodać funkcjonalność ssl do pakietu w dystrybucji pakietowej dajmy na to Ubuntu - zainstalować links-ssl, odinstalować links, tyle że w odwrotnej kolejności. Nie zapomnij za żadne skarby o tym mój drogi czytelniku.
Co należy zrobić w Gentoo - ustawić dla pakietu flagę USE ssl i już. O resztę zadba za Ciebie portage.
Jak ustawić flagę?
- można ustawić ją globalnie - np. w pliku /etc/make.conf poprzez dodanie jej do parametrów zmiennej USE=""
- lokalnie - per pakiet - robimy to w pliku /etc/portage/package.use, wpis wyglada np. tak:
www-clients/links ssl
- w trakcie instalacji pakietu (niezalecane) - ustawiając zmienną USE przy wywołaniu emerge: USE=ssl emerge -av links (Ze względu na to, że flaga ta jest ustawiana przy pojedynczym wywołaniu emerge, jeśli nie dopiszemy ją na stałe pakiet przy następnej aktualizacji zostanie przekompilowany bez ssl)

Kiedy już nauczymy się ręcznie dodawać flagi możemy zacząć używać narzędzia do automatycznego ustawiania flag. Z tego co mi wiadomo działa ono tylko globalnie, tzn. dodaje wpisy w /etc/make.conf, które to tyczą się wszystkich pakietów. Wtedy flagę ssl możemy dodać tak:

# euse -E ssl
Zablokować globalnie kompilację z flagą:
# euse -D ssl
a usunąć wszelkie wpisy z daną flagą z /etc/make.conf tak:
# euse -P ssl

Proponuję przeczytać ze zrozumieniem man euse i wszystko powinno się wyjaśnić. W razie problemów można praktycznie przećwiczyć wszyskie przypadki.
Należy jednak pamiętać o tym, że zmieniamy globalne ustawienia, które są nadpisywane przez ustawienia per pakiet (/etc/portage/portage.use).
Możemy też wyłączać wybrane funkcjonalności - robimy to poprzedzając wybraną flagę znakiem '-' (minus). Działanie jest analogiczne jak w przypadku dodawania flag opisanego powyżej.

Proponuję potestować to u siebie, np. z użyciem opcji 'pretend' (nie instaluj tylko sprawdź) emerge'a:

# emerge -pv links

Dobrze, USE flagi już mamy z grubsza omówione. Wracajmy po tej krótkiej dygresji ;) do głównego wątku - czyli subversion. Skończyliśmy na:

# emerge -av subversion

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] dev-db/sqlite-3.6.13 USE="threadsafe -debug -doc -soundex -tcl" 2,716 kB
[ebuild N ] net-misc/neon-0.28.4 USE="nls ssl zlib -doc -expat -gnutls -kerberos -pkcs11 -socks5" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 758 kB
[ebuild N ] virtual/perl-MIME-Base64-3.07 0 kB
[ebuild N ] dev-perl/URI-1.35 94 kB
[ebuild N ] dev-util/subversion-1.6.2 USE="apache2 berkdb dso nls perl python webdav-neon -bash-completion -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -ruby -sasl -test -vim-syntax -webdav-serf" 5,343 kB

Flagi, które nam się wyświetliły wynikają z ogólnych ustawień systemu, a w szczególności profilu tego systemu (ale o tym następnym razem). Jak widać w wypadku subversion aktywne flagi to:

apache2 berkdb dso nls perl python webdav-neon

Pozostałe flagi są nieaktywne (znak minus) - co oznacza, że dana funkcjonalność, za którą odpowiada flaga będzie niedostępna.
Zestaw flag mniej więcej nam odpowiada - chcemy mieć możliwość udostępniania repozytorium przez apache'a (flaga apache2), flaga webdav umożliwi klientowi svn (subversion) dostęp do repozytoriów poprzez http. Nie chcemy mieć natomiast flagi berkdb, która to określa sposób przechowywania danych w repozytorium. Nie będziemy korzystać z domyślnej bazy Berkley - zamiast niej skorzystamy z nowego systemu przechowywania danych w subversion - a mianowicie z subversion FSFS. O zaletach i wadach konkretnych sposobów przechowywania danych w repozytorium dużo inforamcji znajduje się w svn book, a konkretnie tu.

Skoro wiemy co i jak ma być ustawione - zmieniamy flagi dla pakietu. Ponieważ nie chcę zmieniać ich globalnie - wyłącze je na poziomie pojedynczego pakietu, tzn. w /etc/portage/package.use. Wpis wygląda następująco:

dev-util/subversion -berkdb

Teraz przystąpmy do instalacji

emerge -av subversion

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] dev-db/sqlite-3.6.13 USE="threadsafe -debug -doc -soundex -tcl" 2,716 kB
[ebuild N ] net-misc/neon-0.28.4 USE="nls ssl zlib -doc -expat -gnutls -kerberos -pkcs11 -socks5" LINGUAS="-cs -de -fr -ja -nn -pl -ru -tr -zh_CN" 758 kB
[ebuild N ] virtual/perl-MIME-Base64-3.07 0 kB
[ebuild N ] dev-perl/URI-1.35 94 kB
[ebuild N ] dev-util/subversion-1.6.2 USE="apache2 dso nls perl python webdav-neon -bash-completion -berkdb -ctypes-python -debug -doc -emacs -extras -gnome-keyring -java -ruby -sasl -test -vim-syntax -webdav-serf" 5,343 kB

Total: 5 packages (5 new), Size of downloads: 8,910 kB

Would you like to merge these packages? [Yes/No]

Jak widać flaga berkdb jest nieaktywna - czyli tak jak chcieliśmy. Zatem rozpocznijmy instalację - enter. Następuje konfiguracja i instalacja kolejnych pakietów z powyższej listy, zgodnie z kolejnością ich wyświetlania. Kolejne kroki instalacji odpowiadają krokom, które należy przejść przy ręcznej instalacji pakietu (configure, make, make install). Tyle tylko, że są one zautomatyzowane, ustystematyzowane i zgodne z konwencją (tak bardzo ważne słowo, które znacznie ułatwia życie jeśli się żyje w zgodzie z nim), powtórzmy KONWENCJĄ przyjętą w Gentoo. Zdejmuje to z nas ciężar pamiętania o tym co, gdzie z jakimi flagami i jak zostało zainstalowane. Od tej pory odpowiedzialność za pakiet, a w szczególności jego aktualizacje zrzucamy na barki Gentoo.

i to by było na tyle na dziś...


Przydatne linki:
Gentoo Portage part 1
Gentoo Portage part 2
Subversion Book

PortageXS - narzędzia przydatne w zarządzaniu pakietami

Znalazłem ostatnio w portage'u ciekawy projekt - PortageXS. Jest to napisana w Perl'u (no niestety - nie Ruby - coż) warstwa abstrakcji służąca do zarządzania systemem portage z poziomu skryptu Perl.
Warto zainstalować to narządko w swoim systemie. Można to zrobić tak:

# emerge -av PortageXS

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] dev-perl/PortageXS-0.02.09 USE="-minimal" 0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB

Would you like to merge these packages? [Yes/No]

Po zainstalowaniu warto sprawdzić jakie pliki zostały zainstalowane. To można zrobić za pomocą narzędzia equery, które znajduje się w pakiecie gentoolkit. Jeśli nie macie tego w swoim systemie - pora zainstalować to za pomocą komendy emerge:

# emerge -av gentoolkit

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild N ] app-portage/gentoolkit-0.2.4.5 [0.2.4.2-r1] 87 kB

Total: 1 package (1 new), Size of downloads: 87 kB

Would you like to merge these packages? [Yes/No]

Teraz możemy już wyświetlić listę zainstalowanych przez pakiet PortageXS plików:

equery files PortageXS
[ Searching for packages matching PortageXS... ]
* Contents of dev-perl/PortageXS-0.02.09:
/etc
/etc/init.d
/etc/init.d/portagexsd
/etc/portagexs
/etc/portagexs/categories
/etc/portagexs/certs
/etc/portagexs/init.d

.....

/usr/lib/perl5/vendor_perl/5.8.8/PortageXS/examples/searchPackageByMaintainer.pl
/usr/lib/perl5/vendor_perl/5.8.8/PortageXS/examples/spinner.pl
/usr/sbin
/usr/sbin/portagexsd
/usr/share
/usr/share/doc
/usr/share/doc/PortageXS-0.02.09
/usr/share/doc/PortageXS-0.02.09/Changes.bz2
/usr/share/doc/PortageXS-0.02.09/README.bz2

Są przykładowe skrypty, spróbojmy uruchomić:

# /usr/lib/perl5/vendor_perl/5.8.8/PortageXS/examples/getArch.pl
Arch: x86

i wiele innych, które prezentują możliwości tej biblioteki.

Polecam do lektury:
* man equery
* man emerge

Darmowy system - darmowa nauka

Właśnie pojawiła się w sieci darmowa książka o Linuksie. Niestety (jak dla mnie) wygląda na to, że opiera się ona na dystrybucji SuSE.
hmmm... w sumie nie ma się co dziwić skoro została opracowana przez Novella. Mimo wszystko myślę, że warto się bliżej temu przyjrzeć. Jeżeli korzystamy z Linuksa jako desktopa to jak najbardziej polecam SuSE :).