Neue Funktionen und Optionen in Portage 2.1

Portage 2.1 bringt zahlreiche neue Funktionen und Optionen mit, die ich Ihnen in diesem Dokument vorstellen möchten.

Neue Funktionen und Optionen in Portage 2.1

1. Vorwort

In diesem Artikel möchte ich Ihnen (sicherlich nicht alle) neuen Features und Funktionen vorstellen, sofern möglich mit Beispielen aus der Praxis, als Änderungen in der Handhabung des Paketmanagementsystems. Sollte ich aus Ihrer Sicht wichtige Dinge vergessen haben, schreiben Sie mir bitte eine Email oder posten Sie im Portage 2.1 Thread in den Gentoo Foren.

Bevor Sie sich mit neuen Funktionen und geänderten Handhabungen von Portage 2.1 beschäftigen, werfen Sie bitte einen Blick auf die älteren Artikel zu Portage 2.0.50 und Portage 2.0.51, wie auch auf das "Arbeiten mit Portage" Kapitel des Gentoo Handbuch. Zusätzliche Informationen finden Sie weiterhin in den Release Notes und in der Zusammenfassung neuer Features.

2. Portage 2.1

2.1 Status

Portage 2.1 wurde am 09. Juni veröffentlicht und durch die Architektur-Teams für die meisten der von Gentoo unterstützten Architekturen als "stable" gekennzeichnet.

Die Liste der in Portage 2.1 enthaltenen neuen Features, als auch die Anzahl geschlossener Bugs sind beeindruckend. So konnten mit Portage 2.1 endlich auch nahezu 4 Jahre alte Bugreports geschlossen werden, als Beispiel sei hier das einfo logging genannt. Als wichtigste Änderung ist sicherlich die Überarbeitung des Caching Frameworks zu nennen, die für einen erheblichen Geschwindigkeitszuwachs beim Aktualisieren des Portage Caches sorgt.

2.2 Für die ganz Eiligen: Eine Übersicht neuer Features

• elog Funktionalität zum Mitschreiben von Nachrichten des emerge Prozesses
• Konfigurationsdateien als Verzeichnisse, beispielsweise /etc/portage/package.keywords/
• Ausführen von zusätzlichem Bash-Code in verschiedenen Ebuild Phasen, /etc/portage/bashrc
• FEATURES="parallel-fetch" zum parallelen Download
• Zusätzliche sha256 und rmd160 Hashes für Digests/Manifests
• Neue Option zur rsync Handhabung über PORTAGE_RSYNC_EXTRA_OPTS
• Überarbeitung des Cache-Framworks, dadurch erhebliche Performanceverbesserung

3. Installation

Zur Installation von Portage 2.1 sollten Sie zunächst, sofern noch nicht geschehen, Ihre lokale Kopie des Portage Tree aktualisieren:

# emerge --sync

Nun können Sie Portage 2.1 installieren:

# emerge portage

Im folgenden können Sie mit etc-update eine neue Version der Beispieldatei /etc/make.conf.example installieren - dies ist aber nicht zwingend notwendig.

4. Änderungen in Portage 2.1

4.1 emerge --inject, emerge -U

Beide Funktionen, emerge -i/--inject als auch emerge -U/--upgradeonly, waren bereits in früheren Portage Versionen als veraltet ("deprecated") gekennzeichnet und wurden nun entfernt.

Als Ersatz für emerge --inject benutzen Sie die Datei /etc/portage/profile/package.provided, die Nutzung ist in Portage 2.0.51 beschrieben.

Als Ersatz zu emerge --upgradeonly benutzen Sie die entsprechenden Dateien in /etc/portage/package.*.

4.2 Anordnung der USE Flags

Die Anordnung der USE Flags in der Anzeige hat sich geändert, nun werden aktivierte USE Flags zuerst angezeigt. Sie können die alte, alphabetische, Anordnung durch hinzufügen von --alphabetical zu EMERGE_DEFAULT_OPTS wiederherstellen.

[ebuild   R   ] mail-client/mutt-1.5.11  +berkdb -buffysize -cjk +crypt -debug \
-gdbm -gnutls -gpgme +idn +imap -mbox +nls -nntp -pop -sasl -smime +ssl -vanilla 0 kB

[ebuild   R   ] mail-client/mutt-1.5.11  USE="berkdb crypt gnutls gpgme imap nls \
sasl smime ssl -buffysize -cjk -debug -gdbm -idn -mbox -nntp -pop -vanilla" 0 kB

4.3 Kennzeichnung neuer USE Flags

USE Flags die in einer neuen Version eines Programms erstmals enthalten sind, werden gesondert angezeigt. Dem USE Flag ein % angstellt, das neue USE Flag an sich wird gelb gekennzeichnet.

Anzeige neuer USE Flags im --verbose/-v Modus:

[ebuild     U ] app-cdr/graveman-0.3.12_p5 [0.3.12_p4-r1] USE="dvdr mp3 nls \
vorbis -debug -flac -newuse%" 939 kB

Im nicht gesprächigen Modus werden nur neue USE Flags angezeigt:

[ebuild     U ] app-cdr/graveman-0.3.12_p5 [0.3.12_p4-r1] USE="-newuse%"

4.4 USE_EXPAND

Mit USE_EXPAND wurde einer Möglichkeit geschaffen, erweiterte USE Flags anzuzeigen. Erweiterte USE Flags werden über eigene Variablen angesprochen, beispielswiese LINGUAS oder VIDEO_CARDS und INPUT_DEVICES bei modularem X.org.

Anzeige erweiterter USE Flags mit alter Portage Version bzw. deaktivertem USE_EXPAND:

[ebuild  N    ] kde-base/kde-i18n-3.5.2-r1  USE="kdeenablefinal -arts -debug
-kdehiddenvisibility -linguas_af -linguas_ar -linguas_az -linguas_bg
[....]
-linguas_zh_CN -linguas_zh_TW -xinerama" 0 kB

Anzeige erweiterter USE Flags mit Portage 2.1:

[ebuild  N    ] kde-base/kde-i18n-3.5.2-r1  USE="kdeenablefinal -arts -debug
-kdehiddenvisibility -xinerama" LINGUAS="de -af -ar -az -bg -bn -br -bs -ca
[....]
-se -sk -sl -sr -sr@Latn -ss -sv -ta -tg -tr -uk -uz -zh_CN -zh_TW" 18,963 kB

Die Umgebungsvariablen LINGUAS, VIDEO_CARDS und INPUT_DEVICES können Sie, sofern Sie diese benötigen, in /etc/make.conf setzen.

4.5 Automatische Aktivierung von USE Flags

Bisher wurden USE Flags teilweise automatisch aktiviert, beispielsweise das USE Flag samba, wenn Samba installiert ist oder ldap, wenn OpenLDAP installiert ist. Diese Funktionalität ist in Portage 2.1 standardmässig deaktiviert, Sie können sie durch setzen von auto in USE_ORDER wieder aktivieren. Lesen Sie hierzu auf jeden Fall den entsprechenden Abschnitt von man 5 make.conf.

4.6 emerge sync, emerge info, ...

Unter anderem emerge sync und emerge info sind als veraltet gekennzeichnet worden. Benutzen Sie in Zukunft bitte emerge --sync, bzw. emerge --info. Die als veraltet gekennzeichneten Aufrufe funktionieren weiterhin, die Funktionalität wird allerdings in zukünftigen Portage Veröffentlichungen entfernt werden. Beim Aufruf einer als veraltet gekennzeichneten Funktionalität werden Sie darauf aufmerksam gemacht.

5. Neue Funktionen und Optionen

5.1 Neue FEATURES

In Portage-2.1 gibt es einige neue Optionen, die der FEATURES Variable in /etc/make.conf hinzugefügt werden können. Lesen Sie hierzu auch man make.conf.

FEATURES="parallel-fetch" erlaubt das parallele Downloaden von Sourcen während eines Kompiliervorgangs und bringt somit eine (je nach Geschwindigkeit der Internetverbindung) nicht unerhebliche Geschwindigkeitsverbesserung.

FEATURES="stricter" führt zusätzliche Prüfungen zur Erhöhung der Systemsicherheit auf Text Relocations und Executable Stacks durch. Das Verhalten lässt sich über weitere QA_STRICT_* Variablen anpassen, eine Übersicht darüber enthält man 5 make.conf.

5.2 Konfigurationsdateien als Verzeichnis

Mit der Einführung des Verzeichnisses /etc/portage in Portage 2.0.50 wurde die Flexibilität zur Anpassung der Gentoo Installation deutlich erhöht. So wären USE Flags pro-Paket festlegbar, als auch einfach einzelne Pakete aus dem Testing-Zweig (~arch) der Gentoo Distribution nutzbar.

Portage 2.1 erhöht die Flexibilität erneut, so können nun anstelle einzelner Konfigurationsdateien in /etc/portage diese als Verzeichnis angelegt werden - beispielsweise das Verzeichnis /etc/portage/package.keywords/ anstelle der Datei /etc/portage/package.keywords. Weiterhin können Sie das Verzeichnis auch rekursiv nutzen, also beispielsweise Verzeichnisse für KDE (/etc/portage/package.keywords/kde/) oder Gnome (/etc/portage/package.keywords/gnome) anlegen.

Während die package.keywords Datei nach einigen Monaten und dem ein oder anderen Paket aus dem Testing-Zweig die Tendenz hat, unübersichtlich zu werden, lässt sich diese nun logisch organisieren. Ebenfalls lassen sich nun einfach zusätzliche Dateien einbinden, die nur zeitlich begrenzt benötigt werden - so lässt sich als Beispiel eine Aktualisierung auf eine noch nicht stabile KDE noch einfacher als zuvor handhaben.

Ein /etc/portage/package.keywords/ Verzeichnis kann nun so ausschauen:

# ls /etc/portage/package.keywords/
devel  gnome  kde  lamp  webapps

Die Syntax innerhalb der Dateien hat sich nicht geändert. Analog zu package.keywords lässt sich dies auch auf package.use, package.unmask und weitere anwenden.

5.3 bashrc Framework

Über das neu enthaltene bashrc Framework lässt sich in verschiedenen ebuild-Phasen zusätzlicher bash-Code ausführen. Ein, wie ich finde, gutes Beispiel hierfür hat Gentoo Entwickler Diego Pettenò in der Entwicklermailingliste vorgestellt, das ich hier aufgreifen möchte.

Das Tool localepurge ermöglicht das Löschen von lokalisierten Manpages und lokalisierten Teilen von Programmen, die nicht benötigt werden. So werden schnell einige unnötig belegte Megabyte Festplattenspeicher frei.

Installieren Sie zunächst localepurge:

# emerge localepurge

Passen Sie die Konfigurationsdatei /etc/locale.nopurge nach Ihren Anforderungen an. Beachten Sie, dass diese als "Whitelist" funktioniert und Locales dort enthalten sein sollten, die Sie behalten möchten.

Anstelle localepurge nun händisch oder regelmäßig per Cronjob aufzuraufen, können Sie localepurge auch jedes Mal nach der Installation eines neuen Pakets aufrufen. Hierzu bietet sich die Ebuild-Phase postinst an, in der alle Dateien des Programms bereits aus der Sandbox in das Live-System kopiert wurden.

if [[ ${EBUILD_PHASE} == "postinst" ]]; then
        einfo "Running localepurge..."
        PATH="/bin:/usr/bin" localepurge
fi

Eine Übersicht über die einzelnen Ebuild-Phasen erhalten Sie in man 1 ebuild.

6. Portage Logging mit dem elog Framework

6.1 Einleitung

Einer der Ältesten mit Portage 2.1 geschlossenen Bugs hatte fast vier Jahre auf dem Buckel. Man könnte also fast sagen, "Was lange wärt, wird endlich gut". In Bug 11359 stellte der damalige Gentoo Entwickler Tilman Klar erste Patches für eine Funktionalität zum Loggen der einfo und ewarn Meldungen vor.

6.2 Das elog Framework

Die heutige Implementierung in Portage 2.1 geht über das bloße Loggen hinaus, sie ist Modular aufgebaut und erlaubt es fein granuliert festzulegen, welche Ausgaben wie verarbeitet werden sollen. Hierzu gibt es verschiedene Module, aber es ist auch möglich eigene Verarbeitungskommandos zu definieren.

Die Konfiguration des elog Framework erfolgt über Umgebungsvariablen in /etc/make.conf. Zur Aktivierung müssen Sie die Variable PORTAGE_ELOG_CLASSES zur Auswahl der zu loggenden Elemente setzen. Es stehen folgende Logstufen zur Verfügung:

• info: Nachrichten die als einfo ausgegeben werden
• warn: Nachrichten die als ewarn ausgegeben werden
• error: Fehlermeldungen
• log

Sie können mehrere Logstufen auswählen, müssen aber immer mindestens eine aktivieren.

PORTAGE_ELOG_CLASSES="warn error info"

Im nächsten Schritt wählen Sie das Verarbeitungsmodul aus. Auch hier können mehrere genutzt werden, es muss jedoch mindestens eines aktiviert werden.

• save: Ein Logfile pro Paket wird in $PORT_LOGDIR/elog gespeichert
• syslog: Sendet alle Nachrichten an den Systemlogger
• mail: Sendet pro Paket eine Email-Nachricht
• custom: Führt ein benutzerdefiniertes Kommando aus

Im folgenden Beispiel werden sowohl die Logdateien in $PORT_LOGDIR/elog gespeichert, als auch eine Email-Nachricht pro Paket versandt.

PORTAGE_ELOG_SYSTEM="mail save"

Neben dem custom Modul empfiehlt es sich, das mail Modul anzupassen - klar, Sie wollen ja festlegen, wer die Email-Nachricht empfangen soll. Legen Sie für das mail Modul keine Konfiguration fest, wird versucht die Mail an root@localhost zuzustellen. In diesem Fall muss lokal ein SMTP Server laufen.

Zunächst der Empfänger und der zu benutzende SMTP Server
PORTAGE_ELOG_MAILURI="tobias.scherbaum@gentoo-ev.org localhost"
Alternativ können Sie auch einen SMTP Server des Providers benutzen
PORTAGE_ELOG_MAILURI="tobias.scherbaum@gentoo-ev.org benutzer:passwort@server

Der Absender der Email
PORTAGE_ELOG_MAILFROM="portage@dertobi123.de"

Der Betreff, Sie können die Variablen $PACKAGE und $HOST nutzen
PORTAGE_ELOG_MAILSUBJECT="Paket \${PACKAGE} auf Host \${HOST} mit Nachrichten installiert"

Auch für die Nutzung des custom Modul ist eine weitergehende Konfiguration erforderlich - logisch, sonst wäre es ja nicht "custom" ;) In der Umgebungsvariable PORTAGE_ELOG_COMMAND können Sie ein Script angeben, das die Verarbeitung der Logdatei für Sie übernimmt. Hierbei stehen Ihnen die Variablen $PACKAGE für den Paketnamen und $LOGFILE für den Pfad zu der Logdatei zur Verfügung. So liesse sich beispielsweise ein Script realisieren, welches bei einem fehlgeschlagenen Kompilierungsprozess ein SMNP Trap an einen Nagios Server schickt.

PORTAGE_ELOG_COMMAND="/pfad/zum/programm -p '\${PACKAGE}' -f '\${LOGFILE}'"

Beachten Sie, dass die Variablen hier umgeben von Backticks aufgerufen werden müssen.

7. Zusätzliche Tools

7.1 elogviewer

elogviewer ist ein externes Programm zum grafischen Betrachten der elog-Logfiles. Eine Auswahl der anzuzeigenden Logstufen kann, sofern entsprechende Daten vorhanden sind, vorgenommen werden. Das Programm befindet sich derzeit noch nicht im Portage Tree, ein Ebuild finden Sie im Bugreport, der Autor stellt ebenfalls einen Screenshot zur Verfügung. Eine Diskussion zu elogviewer finden Sie in den Gentoo Foren

7.2 eix

Die aktuelle eix Version 0.55 ist kompatibel zu dem neuen in Portage 2.1 verwendetem Cache Framework. Eine Anleitung zu eix finden Sie im "Tipps und Tricks" Teil des Gentoo Weekly Newsletter vom 12.06.2006.

8. Appendix

8.1 Links

Portage 2.1:

• RELEASE NOTES
• NEWS
• Tracker-Bugreport

Anleitungen zu veralteten Portage Versionen:

• Neue Features in Portage 2.0.50
• Neue Features in Portage 2.0.51

Updates:

• 29. Juni 2007: Informationen zu FEATURES="confcache" entfernt, da confcache auf Grund von zahlreich verursachten Problemen aus dem Portage Tree entfernt wurde.