Gentoo Linux x86 Handbuch: Arbeiten mit Portage
Portage Dateien
Konfigurationsanweisungen
Portage bringt eine Standardkonfiguration mit, die unter /usr/share/portage/config/make.globals gespeichert ist. Jede Konfiguration von Portage findet über Variablen statt. Welche Variablen das sind und was sie bedeuten, wird später beschrieben.
Da viele Konfigurationsanweisungen je nach Architektur unterschiedlich sind, hat Portage auch dafür Standardkonfigurationsdateien, die Teil des Systemprofils sind. Auf dieses Profil wird über den Symlink /etc/portage/make.profile verwiesen. Portages Konfigurationen werden über die make.defaults-Dateien des Profils und all seiner Parent-Profile gesetzt. Später wird mehr auf Profile und das /etc/portage/make.profile-Verzeichnis eingegangen.
Über /etc/portage/make.conf lassen sich die Defaultvariablen übersteuern. Wenn also eine Konfigurationsvariable geändert werden soll, dann in /etc/portage/make.conf und nicht via /usr/share/portage/config/make.globals oder make.defaults. Unter /usr/share/portage/config/make.conf.example findet sich eine Beispiel-make.conf mit weiterführenden Erklärungen. Diese dient jedoch lediglich als Beispiel und wird von Portage nicht ausgewertet.
Es ist ebenfalls möglich eine Portage-Konfigurationsvariable über eine Umgebungsvariable festzulegen, dies wird jedoch nicht empfohlen.
Profil-spezifische Informationen
Es wurde bereits auf das /etc/portage/make.profile-Verzeichnis eingegangen. Dabei handelt es sich um einen symbolischen Link zu einem Profil. Dies ist standardmäßig eines aus /var/db/repos/gentoo/profiles/. Jedoch kann man auch ein eigenes Profil an anderem Ort erstellen und auf dieses verweisen. Das Profil, auf das dieser Symlink zeigt, ist das Profil, dass das komplette System beschreibt.
Ein Profil enthält architekturspezifische Informationen für Portage, wie z.B. eine Liste von Paketen die zu dem jeweiligen System gehören, eine Liste von nicht-funktionierenden (oder maskierten) Paketen, etc.
Nutzer-spezifische Konfiguration
Wenn das Verhalten von Portage bezüglich der Installation von Software geändert werden soll, müssen bestimmte Dateien innerhalb von /etc/portage/ geändert werden. Es wird dringend davon abgeraten, dieses Verhalten über Umgebungsvariablen anzupassen.
Unter /etc/portage/ können Nutzer folgende Dateien erstellen:
- package.mask in der Pakete aufgelistet werden, die von Portage nie in Betracht gezogen werden sollen für eine Installation.
- package.unmask in der Pakete aufgelistet werden, die Portage installieren können soll, obwohl diese von den Gentoo-Entwicklern explizit nicht für die Installation empfohlen werden.
- package.accept_keywords in der Pakete aufgelistet werden, die Portage installieren können soll, obwohl das Paket (noch) nicht für das System oder die Architektur als passend befunden wurde.
- package.use in der die USE-Flags für bestimmte Pakete aufgelistet werden, ohne dass diese für alle Pakete des Systems wirksam werden.
Diese Dateien können auch als Verzeichnisse angelegt werden, die pro Paket eine Datei enthalten. Weitere Informationen über das /etc/portage/-Verzeichnis und eine komplette Liste möglicher Dateien, die darin erstellt werden können, kann man in der Portage-Manpage finden:
user $
man portage
Speicherorte für Portage-Dateien ändern
Die vorhergehenden Konfigurationsdateien können nicht an anderer Stelle gespeichert werden - Portage wird immer an genau diesen Speicherorten nach diesen Dateien suchen. Allerdings nutzt Portage viele andere Speicherorte für verschiedene Zwecke: Build-Ordner, Source Code, Gentoo Repository, ...
All diese Zwecke haben wohlbekannte Standartspeicherorte, können aber nach eigenen Belieben über /etc/portage/make.conf angepasst werden. Der Rest dieses Kapitels erklärt, welche speziellen Speicherorte Portage verwendet und wie diese Orte im Dateisystem geändert werden können.
Dieses Dokument ist allerdings nicht als Referenz gedacht. Eine 100%-Abdeckung liefern nur die Portage- und make.conf-Manpages:
user $
man portage
user $
man make.conf
Speicherorte
Gentoo Ebuild-Repositorium
Der Standardspeicherort für das Gentoo ebuild-Repository ist /var/db/repos/gentoo. Dieser ist definiert von der Standard-repos.conf-Datei unter /usr/share/portage/config/repos.conf. Zum Ändern wird diese Datei nach /etc/portage/repos.conf/gentoo.conf kopiert und unter location angepasst. Wenn das Gentoo ebuild-Repository wo anders gespeichert wird, muss der Symlink unter /etc/portage/make.profile entsprechend mit angepasst werden.
Nachdem der Pfad unter location in /etc/portage/repos.conf/gentoo.conf geändert wurde, wird empfohlen, dass die folgenden Variablen in /etc/portage/make.conf ebenfalls angepasst werden, da diese nicht automatisch durch die location-Änderung mitgeändert werden. Das hat etwas damit zu tun, wie Portage Variablen verarbeitet: PKGDIR, DISTDIR und RPMDIR.
Vorkompilierte Binärdateien
Obwohl Portage standardmäßig keine Binärpakete verwendet, unterstützt es diese. Wenn Portage dafür konfiguriert wird, mit Binärpaketen zu arbeiten, wird es in /var/cache/binpkgs danach suchen. Dieser Pfad über die PKGDIR-Variable definiert.
Quellcode
Der Source Code von Anwendungen wird standardmäßig in /var/cache/distfiles gespeichert. Dieser Pfad wird über die DISTDIR-Variable definiert.
Portage-Datenbank
Portage speichert den Stand des Systems (welche Pakete installiert sind, welche Dateien zu welchen Paket gehören, ...) in /var/db/pkg.
Diese Dateien dürfen nicht manuell geändert werden! Dies könnte dazu führen, dass Portage den Zustand des Systems nicht mehr korrekt auswerten kann.
Portage Cache
Der Portage-Cache (mit Änderungszeiten, virtuelle Pakete, Abhängikeiten, ...) ist in /var/cache/edb gespeichert. Dieser Speicherort ist ein Cache im üblichen Sinne, d.h. man kann den Inhalt jederzeit löschen, solange keine Portage-bezogene Operation läuft.
Bauen von Software
Temporäre Portage-Dateien
Portages temporäre Dateien werden standardmäßig in /var/tmp/ gespeichert. Dieser Pfad wird durch die PORTAGE_TMPDIR-Variable konfiguriert.
Build-Verzeichnis
Portage erstellt für jedes Paket, dass durch emerge installiert wird ein eigenes Build-Verzeichnis innerhalb von /var/tmp/portage/. Dieser Pfad wird durch die PORTAGE_TMPDIR-Variable definiert woran portage/ angehangen wird.
Pfad des Root-Dateisystems
Standardmäßig installiert Portage alle Dateien in das aktuelle Dateisystem (/). Dies kann durch Anpassen der ROOT-Umgebundvariable geändert werden. Dies ist dann sinnvoll, wenn man neue Build-Images erstellt.
Logging-Funktionalitäten
Ebuild-Logging
Portage kann pro ebuild Logdateien erstellen. Dies funktioniert nur, wenn die Variable PORT_LOGDIR einen Pfad angibt, in den von Portage geschrieben werden kann (über den Portage-User). Standardmäßig ist diese Variable nicht gesetzt. Wenn die PORT_LOGDIR nicht gesetzt ist, gibt es keine Build-Logs im aktuellen Logging-System, obwohl Nutzer einige Logs erhalten können über den neuen elog-Support.
Wenn die PORT_LOGDIR-Variable nicht gesetzt ist und elog benutzt wird, werden die Build-Logs und alle anderen von elog erstellten Logs zur Verfügung gestellt, wie folgend beschrieben.
Portage bietet eine feingranulare Kontrolle über das Logging mithilfe von elog:
- PORTAGE_ELOG_CLASSES: Darin können Nutzer bestimmen, welche Art von Nachrichten geloggt werden sollen. Dies kann jede durch Leerzeichen getrennte Kombination von info, warn, error, log und qa sein.
- info: Loggt die "einfo"-Nachrichten, die von ebuilds geschrieben werden
- warn: Loggt die "ewarn"-Nachrichten, die von ebuilds geschrieben werden
- error: Loggt die "eerror"-Nachrichten, die von ebuilds geschrieben werden
- log: Loggt die "elog"-Nachrichten, die in manchen ebuilds verwendet werden
- qa: Loggt die "QA Notice"-Nachrichten, die von ebuilds ausgegeben werden
- PORTAGE_ELOG_SYSTEM: Darüber wird das Modul (oder die Module) ausgewählt, dass die Log-Nachrichten verarbeitet. Wenn dies leer ist, ist das Logging deaktiviert. Jede durch Leerzeichen getrennte Kombination von save, custom, syslog, mail, save_summary und mail_summary kann hier gesetzt werden. Mindestens ein Modul muss ausgewählt werden werden, um elog zu verwenden.
- save: Damit wird ein Log pro Paket in $PORT_LOGDIR/elog oder /var/log/portage/elog, wenn $PORT_LOGDIR nicht gesetzt ist, gespeichert.
- custom: Damit werden alle Nachrichten zu einem eigenen Befehl weitergeleitet, der über $PORTAGE_ELOG_COMMAND definiert wird; dazu später mehr.
- syslog: Sendet alle Nachrichten an den installierten System Logger.
- mail: Leitet alle Nachrichten zu einem Nutzer-definierten Mailserver via $PORTAGE_ELOG_MAILURI weiter; dazu später mehr. Das Mail-Feature von elog ist verfügbar ab >=portage-2.1.1.
- save_summary: Ähnlich wie save, nur dass hier die Nachrichten zusammengefasst gespeichert werden unter $PORT_LOGDIR/elog/summary.log oder /var/log/portage/elog/summary.log, wenn $PORT_LOGDIR nicht definiert ist.
- mail_summary: Ähnlich wie mail, nur dass alle Nachrichten in einer einzigen Mail gesendet werden, wenn emerge fertig ist.
- PORTAGE_ELOG_COMMAND: Dies wird nur ausgewertet, wenn das custom-Modul aktiviert ist. Nutzer können damit einen Befehl definieren, der die Nachrichten verarbeitet. Beachte, dass dem Befehl zwei Variablen zur Verfügung stehen: ${PACKAGE} enthält den Paketnamen mit Version und ${LOGFILE} enthält den absoluten Pfad zu der Logdatei. Zum Beispiel:
PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"
- PORTAGE_ELOG_MAILURI: Darin enthalten sind Einstellungen für das mail-Modul, wie z.B. Adresse, Nutzername, Passwort, Mailserver und Portnummer. Der Standard ist "root@localhost localhost". Im folgenden ein Beispiel für einen SMTP-Server der eine Nutzernamen- und Passwort-basierte Authentifizierung auf einem bestimmten Port (Standard ist 25) verlangt:
PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"
- PORTAGE_ELOG_MAILFROM: Darüber kann die "from"-Adresse der Log-Mails gesetzt werden, wenn nicht gesetzt, ist dies defaultmäßig "Portage".
- PORTAGE_ELOG_MAILSUBJECT: Darüber kann der Betreff der Log-Mail bestimmt werden. Es stehen hier die beiden Variablen ${PACKAGE} und ${HOST} zur Verfügung, die den Paketnamen mit Version und den Fully Qualified Domain Name des Portage-Hosts enthält.
Zum Beispiel:
PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST} with some messages"
Nutzer die enotice mit Portage-2.0.* benutzt haben müssen enotice komplett entferten, da dies nicht mit elog kompatibel ist.
Portage configuration
As noted previously, Portage is configurable through many variables which should be defined in /etc/portage/make.conf or one of the subdirectories of /etc/portage/. Please refer to the make.conf and portage man pages for more and complete information:
user $
man make.conf
user $
man portage
Build-specific options
Configure and compiler options
When Portage builds applications, it passes the contents of the following variables to the compiler and configure script:
- CFLAGS and CXXFLAGS
- Define the desired compiler flags for C and C++ compiling.
- CHOST
- Defines the build host information for the application's configure script
- MAKEOPTS
- Passed to the make command and is usually set to define the amount of parallelism used during the compilation. More information about the make options can be found in the make man page.
The USE variable is also used during configure and compilations but has been explained in great detail in previous chapters.
Merge options
When Portage has merged a newer version of a certain software title, it will remove the obsoleted files of the older version from the system. Portage gives the user a 5 second delay before unmerging the older version. These 5 seconds are defined by the CLEAN_DELAY variable.
It is possible to tell emerge to use certain options every time it is run by setting EMERGE_DEFAULT_OPTS. Some useful options would be --ask
, --verbose
, --tree
, and so on.
Configuration file protection
Portage protected locations
Portage overwrites files provided by newer versions of a software title if the files aren't stored in a protected location. These protected locations are defined by the CONFIG_PROTECT variable and are generally configuration file locations. The directory listing is space-delimited.
A file that would be written in such a protected location is renamed and the user is warned about the presence of a newer version of the (presumable) configuration file.
To find out about the current CONFIG_PROTECT setting, use the emerge --info output:
user $
emerge --info | grep 'CONFIG_PROTECT='
More information about Portage's configuration file protection is available in the CONFIGURATION FILES section of the emerge manpage:
user $
man emerge
Excluding directories
To 'unprotect' certain subdirectories of protected locations users can use the CONFIG_PROTECT_MASK variable.
Download options
Server locations
When the requested information or data is not available on the system, Portage will retrieve it from the Internet. The server locations for the various information and data channels are defined by the following variables:
- GENTOO_MIRRORS
- Defines a list of server locations which contain source code (distfiles).
- PORTAGE_BINHOST
- Defines a particular server location containing prebuilt packages for the system.
A third setting involves the location of the rsync server which users use to update their local Gentoo repository. This is defined in the /etc/portage/repos.conf file (or a file inside that directory if it is defined as a directory):
- sync-type
- Defines the type of server and defaults to
rsync
. - sync-uri
- Defines a particular server which Portage uses to fetch the Gentoo repository.
The GENTOO_MIRRORS, sync-type, and sync-uri variables can be set automatically through the mirrorselect application. Of course, app-portage/mirrorselect needs to be installed first before it can be used. For more information, see mirrorselect's online help:
root #
mirrorselect --help
If the environment requires the use of a proxy server, then the http_proxy, ftp_proxy, and RSYNC_PROXY variables can be declared.
Fetch commands
When Portage needs to fetch source code, it uses wget by default. This can be changed through the FETCHCOMMAND variable.
Portage is able to resume partially downloaded source code. It uses wget by default, but this can be altered through the RESUMECOMMAND variable.
Make sure that the FETCHCOMMAND and RESUMECOMMAND store the source code in the correct location. Inside the variables the \${URI} and \${DISTDIR} variables can be used to point to the source code location and distfiles location respectively.
It is also possible to define protocol-specific handlers with FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP, and so on.
Rsync settings
It is not possible to alter the rsync command used by Portage to update the Gentoo repository, but it is possible to set some variables related to the rsync command:
- PORTAGE_RSYNC_OPTS
- Sets a number of default variables used during sync, each space-separated. These shouldn't be changed unless you know exactly what you're doing. Note that certain absolutely required options will always be used even if PORTAGE_RSYNC_OPTS is empty.
- PORTAGE_RSYNC_EXTRA_OPTS
- Used to set additional options when syncing. Each option should be space separated:
--timeout=<number>
- This defines the number of seconds an rsync connection can idle before rsync sees the connection as timed-out. This variable defaults to
180
but dialup users or individuals with slow computers might want to set this to300
or higher. --exclude-from=/etc/portage/rsync_excludes
- This points to a file listing the packages and/or categories rsync should ignore during the update process. In this case, it points to /etc/portage/rsync_excludes.
--quiet
- Reduces output to the screen.
--verbose
- Prints a complete filelist.
--progress
- Displays a progress meter for each file.
- PORTAGE_RSYNC_RETRIES
- Defines how many times rsync should try connecting to the mirror pointed to by the SYNC variable before bailing out. This variable defaults to
3
.
For more information on these options and others, please read man rsync.
Gentoo configuration
Branch selection
It is possible to change the default branch with the ACCEPT_KEYWORDS variable. It defaults to the architecture's stable branch. More information on Gentoo's branches can be found in the next chapter.
Portage features
It is possible to activate certain portage features through the FEATURES variable. The Portage features have been discussed in previous chapters.
Portage behavior
Resource management
With the PORTAGE_NICENESS variable users can augment or reduce the nice value Portage will use while running. The PORTAGE_NICENESS value is added to the current nice value of Portage.
For more information about nice values, see Portage niceness and the nice man page:
user $
man nice
Output behavior
The NOCOLOR variable, which defaults to false
, defines if Portage should disable the use of colored output.
Using one branch
Stable
The ACCEPT_KEYWORDS variable defines the system's software branch. This variable is set in the /etc/portage/make.conf file and is configured to the stable branch by default. In this instance the default value is x86.
# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="x86"
For a more casual experience, and less risk of instability or other issues, the Handbook recommends staying on the stable software branch. Since this is Portage's default behavior no changes are necessary. System administrators who want to live dangerously or receive the latest possible software updates should read the Testing section.
Testing
Hic sunt dracones! Running software from the testing branch may incur stability issues, imperfect package handling (for instance wrong/missing dependencies), frequent ebuild revisions (resulting in a lot of compiling) or packages that are broken in another, often unexpected, manner. System administrators who are less comfortable with Gentoo or Linux in general should avoid the testing branch. As noted previously, the Handbook recommends staying with the stable, more thoroughly tested branch.
In cases where the system administrator would like to run a less-tested software stack, and in exchange receive 'bleeding edge' updates, the testing branch can be selected. To switch to the testing branch, set the ACCEPT_KEYWORDS value to ~x86.
# Instructing Portage to use the testing branch (~) for the amd64 architecture.
ACCEPT_KEYWORDS="~x86"
Any architecture supported by the Gentoo project can move to a testing branch by simply adding a ~
(tilde symbol) in front of the architecture's ACCEPT_KEYWORDS value.
The testing branch is exactly what one would expect - unstable. If a package is in testing, it means that the developers believe it is functional but has not been thoroughly tested. Systems using the testing branch may be the first to encounter bugs in the package. If bugs are discovered, please file a bug report to make the developer(s) aware.
When changing from the stable to the testing branch and performing a @world update, it is normal for many - sometimes hundreds - of packages to be updated to the latest available versions. Updates generally correspond to the upstream project's current release. Keep in mind that, after moving from stable to testing, it may prove a challenge to revert back to the stable branch. This is to be expected.
Mixing stable with testing
package.accept_keywords
It is possible to instruct Portage to allow the testing branch for particular packages, but use the stable branch for the rest of the system. To achieve this, add the package category and name into the /etc/portage/package.accept_keywords file. It is also possible to create a directory (with the same name) and list the package in a file under the directory.
For instance, to use the testing branch for gnumeric:
app-office/gnumeric
Testing particular versions
To use a specific software version from the testing branch but not allow updates from the testing branch for subsequent versions, a specific version of the package can be defined in the package.accept_keywords file. To define a specific version, the =
operator is utilized. It is also possible to enter a version range using the <=
, <
, >
or >=
operators.
In any case, if any package version information is defined, an operator must be used. Without version information, an operator cannot be used.
In the following Portage is instructed to allow the installation of a specific version of gnumeric, version 1.2.13, even if it is in the testing branch:
=app-office/gnumeric-1.2.13
Masked packages
package.unmask
Gentoo developers mask packages for good reason, therefore unmasking a package is generally unsupportable by Gentoo's support channels. For this reason, it is to be expected for support requests related to package.unmask and/or package.mask to be ignored or marked as WONTFIX. Please exercise due caution when unmasking packages.
For the next example, presume a package has been masked by the Gentoo developers. When attempting to install the package, Portage will output a message indicating the package has been masked and will generally provide a reason for its masking. Next presume a system administrator, despite the reason mentioned in the package.mask file (situated in /var/db/repos/gentoo/profiles/ by default) still desires to install the package.
To do so, the system administrator would add the target package version (usually this will be the exact same line from the package.mask file in the profile) to the /etc/portage/package.unmask location.
For instance, if =mail-client/mutt-2.2.9
is masked (poor doggy!), then it can be unmasked by adding the exact same line in the package.unmask location:
=mail-client/mutt-2.2.9
If an entry in /var/db/repos/gentoo/profiles/package.mask contains a range of package versions, then it is necessary to unmask only the version(s) that are actually needed. Please read the previous section to learn how to specify versions using operators.
package.mask
It is also possible to instruct Portage to not install a certain package or not update to a specific version of a package. This is called masking a package. To mask a package, add qualifiers as necessary to the /etc/portage/package.mask location (either in that file or in a file in this directory).
For instance, to prevent Portage from installing kernel sources newer than gentoo-sources-6.6.21, add the following line at the package.mask location:
>sys-kernel/gentoo-sources-6.6.21
dispatch-conf
dispatch-conf is a tool that aids in merging the ._cfg0000_<name> files. ._cfg0000_<name> files are generated by Portage when it wants to overwrite a file in a directory protected by the CONFIG_PROTECT variable.
With dispatch-conf, users are able to merge updates to their configuration files while keeping track of all changes. dispatch-conf stores the differences between the configuration files as patches or by using the RCS revision system. This means that if someone makes a mistake when updating a config file, the administrator can revert the file to the previous version at any time.
When using dispatch-conf, users can ask to keep the configuration file as-is, use the new configuration file, edit the current one or merge the changes interactively. dispatch-conf also has some nice additional features:
- Automatically merge configuration file updates that only contain updates to comments.
- Automatically merge configuration files which only differ in the amount of whitespace.
Edit /etc/dispatch-conf.conf first and create the directory referenced by the archive-dir variable. Then, execute dispatch-conf:
root #
dispatch-conf
When running dispatch-conf, each changed config file will be reviewed one at a time. Press u to update (replace) the current config file with the new one and continue to the next file. Press z to zap (delete) the new config file and continue to the next file. The n key will instruct dispatch-conf to skip to the next file. This can be done to delay a merge until a future time. Once all config files have been taken care of, dispatch-conf will exit. At any time, q can be used to exit the application as well.
For more information, check out the dispatch-conf man page. It describes how to interactively merge current and new config files, edit new config files, examine differences between files, and more.
user $
man dispatch-conf
quickpkg
With quickpkg users can create archives of the packages that are already merged on the system. These archives can be used as prebuilt packages. Running quickpkg is straightforward: just add the names of the packages to archive.
For instance, to archive curl, orage, and procps:
root #
quickpkg curl orage procps
The prebuilt packages will be stored in $PKGDIR (/var/cache/binpkgs/ by default). These packages are placed in $PKGDIR/CATEGORY.
Eine Untermenge des Gentoo-Repositoriums verwenden
Pakete und Kategorien ausschließen
Es ist möglich selektiv bestimmte Kategorien/Pakete zu aktualisieren und die anderen Kategorien/Pakete zu ignorieren. Dies können Sie dadurch erreichen, indem Sie rsync währen dem emerge --sync Schritt Kategorien/Pakete ausschließen lassen.
Damit diese Methode funktioniert, muss die Manifestüberprüfung deaktiviert werden, was die Sicherheit des Repositoriums verringert. Um die Überprüfung zu deaktivieren, deaktivieren Sie entweder das USE-Flag rsync-verify auf sys-apps/portage oder setzen Sie sync-rsync-verify-metamanifest=no im repos.conf-Eintrag des Gentoo-Repositorium.
Definieren Sie den Namen der Datei, die das Ausschluss-Muster beinhaltet in der Variable PORTAGE_RSYNC_EXTRA_OPTS in /etc/portage/make.conf:
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"
games-*/*
Beachten Sie, dass dieses Vorgehen zu Abhängigkeits-Problemen führen kann, da neue erlaubte Pakete von neuen aber ausgeschlossenen Paketen abhängig sein können.
Inoffizielle ebuilds hinzufügen
Ein benutzerdefiniertes Ebuild-Repositorium definieren
Manual creation
Es ist möglich Portage anzuweisen Ebuilds zu verwenden, die nicht offiziell durch das Gentoo Ebuild-Repositorium verfügbar sind. Zu diesem Zweck erzeugen Sie ein neues Verzeichnis (z.B. /var/db/repos/localrepo), in dem die Ebuilds von Drittanbietern untergebracht werden. Dieses neue Repositorium erfordert die gleiche Verzeichnisstruktur wie beim offiziellen Gentoo-Repositorium!
root #
mkdir -p /var/db/repos/localrepo/{metadata,profiles}
root #
chown -R portage:portage /var/db/repos/localrepo
Als nächstes wählen Sie einen sinnvollen Namen für das Repositorium. Im nächsten Beispiel wird "localrepo" als Name verwendet:
root #
echo 'localrepo' > /var/db/repos/localrepo/profiles/repo_name
Then define the EAPI used for the profiles within the repository:
root #
echo '8' > /var/db/repos/localrepo/profiles/eapi
Sagen Sie Portage, dass der Repositorium-Master das Haupt-Gentoo-Ebuild-Repositorium ist und dass das lokale Repositorium nicht automatisch synchronisiert werden soll (da es nicht von einer externen Quelle wie einem rsync-Server, Git-Mirror oder einem anderen Repositorientyp gesichert wird):
masters = gentoo
auto-sync = false
Schließlich aktivieren Sie das Repositorium auf dem lokalen System, indem Sie eine Repositorium-Konfigurationsdatei in /etc/portage/repos.conf erstellen. Dies wird Portage darüber informieren, wo das benutzerdefinierte lokale Repositorium gefunden werden kann:
[localrepo]
location = /var/db/repos/localrepo
Optional: Creating a repo using eselect repository
Alternatively, a custom ebuild repository can be quickly created using the eselect repository module (from app-eselect/eselect-repository). In the following example, substitute localrepo
with a name of choice:
root #
eselect repository create localrepo
Adding localrepo to /etc/portage/repos.conf/eselect-repo.conf ... Repository <ebuild_repository_name> created and added
A bare repository named "localrepo" will be made available at /var/db/repos/localrepo.
Mit mehreren Overlays arbeiten
For those desiring to develop several ebuild repos, test packages before they hit the Gentoo repository, or who want to use unofficial ebuilds from various sources, the app-eselect/eselect-repository package also provides tooling to aid in keeping repositories up to date. See also eselect repository article.
eselect-repository
Aktivieren Sie beispielsweise das hardened-development Overlay:
root #
eselect repository enable hardened-development
root #
emerge --sync
Nicht von Portage gepflegte Software
Verwendung von Portage mit selbst-gewarteter Software
Manchmal möchte der Benutzer Software individuell konfigurieren, installieren und warten ohne dass Portage den Vorgang automatisiert, obwohl Portage die Software-Titel bereitstellen kann. Bekannte Fälle sind die Kernel-Quellen und NVIDIA-Treiber. Es ist möglich Portage so zu konfigurieren, dass es weiß dass bestimmte Pakete manuell auf dem System installiert wurden (und diese Information deshalb bei der Berechnung von Abhängigkeiten berücksichtigt wird). Dieser Vorgang wird Injektion genannt und wird von Portage durch die Datei /etc/portage/profile/package.provided unterstützt.
Um beispielsweise Portage über gentoo-sources-6.6.21 zu informieren, das manuell installiert wurde, fügen Sie zu /etc/portage/profile/package.provided die folgende Zeile hinzu:
sys-kernel/gentoo-sources-6.6.21
Dies ist eine Datei, die Versionen ohne
=
Operator verwendet.
Introduction to Portage's advanced features
For most readers, the information received thus far is sufficient for all their Linux operations. But Portage is capable of much more; many of its features are for advanced customization purposes or are only applicable in specific corner cases.
Of course, with lots of flexibility comes a huge list of potential cases. It will not be possible to document them all here. Instead, the goal is to focus on some generic issues which can then be augmented to fit a particular niche. More tweaks and tips such as these can be found across the Gentoo wiki.
Most, if not all, of these additional features can be easily found by digging through the manual pages that are provided with Portage:
user $
man portage
user $
man make.conf
Finally, know that these are advanced features which, if not configured correctly, can make debugging and troubleshooting much more difficult. Be sure any of these sorts of customization is explicitly mentioned when opening a bug report.
Per-package environment variables
Using /etc/portage/env
By default, package builds will use the environment variables defined in /etc/portage/make.conf, such as CFLAGS, MAKEOPTS and others. In some cases, it is beneficial to provide different variables for specific packages. To do so, Portage supports the use of the /etc/portage/env directory and /etc/portage/package.env file.
The /etc/portage/package.env file contains a list of packages for which deviating environment variables are needed as well as a specific identifier that indicates to Portage which identifier file to apply. The identifier name is free format. Portage will look for a file with the exactly same case-sensitive name as the identifier. See the following example for more detail.
Example: Using debugging for specific packages
As an example, to enable debugging for the media-video/mplayer package.
Set the debugging variables in a file called /etc/portage/env/debug-cflags. The filename is arbitrarily chosen, but of course the name reflects the purpose of the file, which should make it obvious if reviewing later why the file exists. The /etc/portage/env directory will need created if it does not yet exist:
root #
mkdir /etc/portage/env
# Add -ggdb to CFLAGS for debugging
CFLAGS="-O2 -ggdb -pipe"
FEATURES="${FEATURES} nostrip"
Next, the media-video/mplayer package is 'tagged' to use the new debug identifier in the package.env file:
media-video/mplayer debug-cflags
Hooking into the emerge process
Using /etc/portage/bashrc and affiliated files
When Portage works with ebuilds, it uses a bash environment in which it calls the various build functions (like src_prepare
, src_configure
, pkg_postinst
, etc.). Portage allows system administrators to set up a specific bash environment.
The advantage of using a specific bash environment is that it allows for hooks into the emerge process during each step it performs. This can be done for every emerge (through /etc/portage/bashrc) or by using per-package environments (through /etc/portage/env as discussed earlier).
To hook in the process, the bash environment can listen to the variables EBUILD_PHASE, CATEGORY as well as the variables that are always available during ebuild development (such as P, PF, ...). Based on the values of these variables additional steps and/or functions can be executed.
Example: Updating the file database
In this example, the /etc/portage/bashrc file will be used to call some file database applications in order to ensure their databases are up to date with the system. The applications used in the example are aide (an intrusion detection tool) and updatedb (to use with mlocate), but these are meant as examples. Do not consider this as a guide for AIDE.
To use /etc/portage/bashrc for this case, we need to "hook" in the postrm
(after removal of files) and postinst
(after installation of files) functions, because that is when the files on the file system have been changed.
if [ "${EBUILD_PHASE}" == "postinst" ] || [ "${EBUILD_PHASE}" == "postrm" ];
then
echo ":: Calling aide --update to update its database"
aide --update
echo ":: Calling updatedb to update its database"
updatedb
fi
Executing tasks after ebuild repository syncs
Using /etc/portage/postsync.d location
In addition to hooking into the ebuild phases, Portage offers another option for hook functionality: postsync.d. These types of hooks are run after updating, also referred to as syncing, the Gentoo ebuild repository. In order to run tasks after updating the Gentoo repository, put scripts inside the /etc/portage/postsync.d directory. Be sure any files inside the directory have been marked as executable or they will not run.
Example: Running eix-update
If eix-sync was not used to update sync the repository, then it is still possible to update the eix database after running emerge --sync (or emerge-webrsync) by putting a symlink to /usr/bin/eix called eix-update in /etc/portage/postsync.d.
root #
ln -s /usr/bin/eix /etc/portage/postsync.d/eix-update
If a different name is chosen, then it needs to be a script that calls /usr/bin/eix-update instead. The eix binary looks at how it has been called to determine which function to execute. If a symlink were created that pointed to eix yet was not called eix-update, it would not run correctly.
Overriding profile settings
Using /etc/portage/profile
By default, Gentoo uses the settings contained in the profile pointed to by /etc/portage/make.profile, which is a symbolic link to the target profile directory. These profiles define both specific settings as well as inherit settings from other profiles (through their parent files).
By using /etc/portage/profile, system administrators can override profile settings such as packages (what packages are considered to be part of the system set), forced USE flags, and more.
Example: Adding nfs-utils to the system set
When using an NFS-based file systems for critical file systems, it might be necessary to mark net-fs/nfs-utils as a system package, which will cause Portage to heavily warn administrators in the event they would attempt to unmerge it.
To accomplish this, the package must be added to the /etc/portage/profile/packages file, prepended with a *
(asterisk symbol):
*net-fs/nfs-utils
Applying non-standard patches
Patching source code using user patches in /etc/portage/patches/
User patches provide a way to apply patches to package source code when sources are extracted before installation. This can be useful for applying upstream patches to unresolved bugs, or simply for local customizations.
Patches need to be dropped into /etc/portage/patches/. They will automatically be applied during package installation.
Patches can be dropped into any of the following directories:
- /etc/portage/patches/${CATEGORY}/${P}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r1/
- /etc/portage/patches/${CATEGORY}/${PN}/ e.g. /etc/portage/patches/dev-lang/python-3.4.2/
- /etc/portage/patches/${CATEGORY}/${P}-${PR}/ e.g. /etc/portage/patches/dev-lang/python-3.3.5-r0/
Example: Applying patches to Firefox
The www-client/firefox package is one of the many that already call eapply_user
(possibly implicitly) from within the ebuild, so there is no need to override anything specific.
If for some reason (for instance because a developer provided a patch and asked to check if it fixes the bug reported) patching Firefox is wanted, all that is needed is to put the patch in /etc/portage/patches/www-client/firefox/ (it might be best to use the full name and version so that the patch does not interfere with later versions) and rebuild Firefox.
Warning: Display title "Gentoo Linux x86 Handbuch: Arbeiten mit Portage" overrides earlier display title "Handbuch:X86/Komplett/Portage".