Gentoo Linux hppa Handbook: Working with Portage

This page is a translated version of the page Handbook:HPPA/Full/Portage and the translation is 100% complete.

Portage கோப்புகள்

உள்ளமைவு வழிகாட்டுதல்கள்

Portage ஆனது /usr/share/portage/config/make.globals இல் சேமித்து வைக்கப்பட்டுள்ள முன்னிருப்பு உள்ளமைவுகளோடு கிடைக்கிறது. எல்லா Portage உள்ளமைவுகளும் மாறிகள் மூலம் கையாளப்படுகிறது. என்ன மாறிகளை portage கவனிக்கிறது என்பதையும் அதன் பொருள் என்ன என்பதையும் பின்னர் விரிவாகக் காணலாம்.

Since many configuration directives differ between architectures, Portage also has default configuration files which are part of the system profile. This profile is pointed to by the /etc/portage/make.profile symlink; Portage's configurations are set in the make.defaults files of the profile and all parent profiles. We'll explain more about profiles and the /etc/portage/make.profile directory later on.

When changing a configuration variable, do not alter /usr/share/portage/config/make.globals or make.defaults. Instead use /etc/portage/make.conf which has precedence over the previous files. For more information, read the /usr/share/portage/config/make.conf.example. As the name implies, this is merely an example file - Portage does not read in this file.

It is also possible to define a Portage configuration variable as an environment variable, but we don't recommend this.

தனியமைப்பு-சார்ந்த தகவல்கள்

We've already encountered the /etc/portage/make.profile directory. Well, this is not exactly a directory but a symbolic link to a profile, by default one inside /var/db/repos/gentoo/profiles/ although one can create their own profiles elsewhere and point to them. The profile this symlink points to is the profile to which the system adheres.

A profile contains architecture-specific information for Portage, such as a list of packages that belong to the system corresponding with that profile, a list of packages that don't work (or are masked-out) for that profile, etc.

பயனர்-சார்ந்த உள்ளமைவு

When Portage's behavior needs to be changed regarding the installation of software, then the right set of files inside /etc/portage/ will need to be changed. It is highly recommended to use files within /etc/portage/ and highly discouraged to override the behavior through environment variables!

Within /etc/portage/ users can create the following files:

package.mask which lists the packages that Portage should never try to install
package.unmask which lists the packages Portage should be able to install even though the Gentoo developers highly discourage users from emerging them
package.accept_keywords which lists the packages Portage should be able to install even though the package hasn't been found suitable for the system or architecture (yet)
package.use which lists the USE flags to use for certain packages without having the entire system use those USE flags

These don't have to be files; they can also be directories that contain one file per package. More information about the /etc/portage/ directory and a full list of possible files that can be created can be found in the Portage man page:

user $man portage

Portage கோப்பு மற்றும் அடைவு இருப்பிடங்களை மாற்றுதல்

The previously mentioned configuration files cannot be stored elsewhere - Portage will always look for those configuration files at those exact locations. However, Portage uses many other locations for various purposes: build directory, source code storage, Gentoo repository location, ...

All these purposes have well-known default locations but can be altered to personal taste through /etc/portage/make.conf. The rest of this chapter explains what special-purpose locations Portage uses and how to alter their placement on the filesystem.

This document isn't meant to be used as a reference though. To get 100% coverage, please consult the Portage and make.conf man pages:

user $

man portage

user $man make.conf

கோப்புகளைச் சேமித்தல்

சென்டூ ebuild கருவூலம்

The default location of the Gentoo ebuild repository is at /var/db/repos/gentoo. This is defined by the default repos.conf file found at /usr/share/portage/config/repos.conf. To modify the default, copy this file to /etc/portage/repos.conf/gentoo.conf and change the location setting. When storing the Gentoo ebuild repository elsewhere (by altering this variable), don't forget to change the /etc/portage/make.profile symbolic link accordingly.

After changing the location setting in /etc/portage/repos.conf/gentoo.conf, it is recommended to alter the following variables in /etc/portage/make.conf as well since they will not notice the location change. This is due to how Portage handles variables: PKGDIR, DISTDIR, and RPMDIR.

முன் கட்டப்பட்ட இருமத் தொகுதிகள்

Even though Portage doesn't use pre-built binaries by default, it has extensive support for them. When asking Portage to work with pre-built packages, it will look for them in /var/cache/binpkgs. This location is defined by the PKGDIR variable.

மூல நிரல்

Application source code is stored in /var/cache/distfiles by default. This location is defined by the DISTDIR variable.

Portage தரவகம்

Portage stores the state of the system (what packages are installed, what files belong to which package, ...) in /var/db/pkg.

எச்சரிக்கை
Do not alter the system state files manually! It might break Portage's knowledge of the system.

Portage பதுக்ககம்

The Portage cache (with modification times, virtuals, dependency tree information, ...) is stored in /var/cache/edb. This location really is a cache: users can clean it if they are not running any Portage-related application at that moment.

மென்பொருளைக் கட்டுதல்

தற்காலிக portage கோப்புகள்

இயல்பாக Portage இன் தற்காலிக கோப்புகள் /var/tmp/ என்னும் இடத்தில் சேமித்து வைக்கப்பட்டிருக்கும். இதை PORTAGE_TMPDIR என்னும் மாறி வரையறுக்கிறது.

அடைவைக் கட்டுதல்

Portage ஆனது அது emerge செய்யும் ஒவ்வொரு தொகுப்பிற்கும் ஒரு குறிப்பிட்ட கட்டு அடைவை /var/tmp/portage/ என்னும் இடத்திற்குள் உருவாக்குகிறது. இந்த இடம் portage/ ஆல் கடையிணைப்பு செய்யப்பட்ட PORTAGE_TMPDIR மாறியால் வரையறுக்கப்பட்டுள்ளது.

நிகழ் கோப்பு முறைமை இருப்பிடம்

By default Portage installs all files on the current filesystem (/), but this can be changed by setting the ROOT environment variable. This is useful when creating new build images.

குறிப்புப்பதிவிடல் தனிச்சிறப்புகள்

இ-கட்டு (Ebuild) குறிப்புப்பதிவிடல்

Portage can create per-ebuild log files, but only when the PORT_LOGDIR variable is set to a location that is writable by Portage (through the Portage user). By default this variable is unset. If PORT_LOGDIR is not set, then there will not be any build logs with the current logging system, though users may receive some logs from the new elog support.

If PORT_LOGDIR is not defined and elog is used, then build logs and any other logs saved by elog will be made available, as explained below.

Portage offers fine-grained control over logging through the use of elog:

PORTAGE_ELOG_CLASSES: இவ்விடத்தில் பயனர்கள் என்ன செய்திகளை குறிப்புப்பதிவு செய்து வைத்துக்கொள்ளலாம் என்பதை வரையறுத்துக்கொள்ளலாம். இது info, warn, error, log மற்றும் qa ஆகியவற்றின் ஏதாவதொரு இடைவெளியால்-பிரிக்கப்பட்ட கூட்டாக இருக்கலாம்.
- info: ebuild ஆல் அச்சடிக்கப்பட்ட "einfo" செய்திகளை குறிப்புப்பதிவு செய்கிறது.
- warn: ebuild ஆல் அச்சடிக்கப்பட்ட "ewarn" செய்திகளை குறிப்புப்பதிவு செய்கிறது.
- error: ebuild ஆல் அச்சடிக்கப்பட்ட "eerror" செய்திகளை குறிப்புப்பதிவு செய்கிறது.
- log: சில ebuild களால் கண்டறியப்பட்ட "elog" செய்திகளை குறிப்புப்பதிவு செய்கிறது.
- qa: ebuild ஆல் அச்சடிக்கப்பட்ட "QA Notice" செய்திகளை குறிப்புப்பதிவு செய்கிறது.

PORTAGE_ELOG_SYSTEM: This selects the module(s) to process the log messages. If left empty, logging is disabled. Any space-separated combination of save, custom, syslog, mail, save_summary, and mail_summary can be used. At least one module must be used in order to use elog.
- save: This saves one log per package in $PORT_LOGDIR/elog, or /var/log/portage/elog if $PORT_LOGDIR is not defined.
- custom: Passes all messages to a user-defined command in $PORTAGE_ELOG_COMMAND; this will be discussed later.
- syslog: Sends all messages to the installed system logger.
- mail: Passes all messages to a user-defined mailserver in $PORTAGE_ELOG_MAILURI; this will be discussed later. The mail features of elog require >=portage-2.1.1.
- save_summary: Similar to save, but it merges all messages in $PORT_LOGDIR/elog/summary.log, or /var/log/portage/elog/summary.log if $PORT_LOGDIR is not defined.
- mail_summary: Similar to mail, but it sends all messages in a single mail when emerge exits.

PORTAGE_ELOG_COMMAND: This is only used when the custom module is enabled. Users can specify a command to process log messages. Note that the command can make use of two variables: ${PACKAGE} is the package name and version, while ${LOGFILE} is the absolute path to the logfile. For instance:

குறிமுறை எடுத்துக்காட்டு PORTAGE_ELOG_COMMAND வரையறுத்தல்

PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"

PORTAGE_ELOG_MAILURI: This contains settings for the mail module such as address, user, password, mail server, and port number. The default setting is "root@localhost localhost". The following is an example for an SMTP server that requires username and password-based authentication on a particular port (the default is port 25):

குறிமுறை Example PORTAGE_ELOG_MAILURI definition

PORTAGE_ELOG_MAILURI="user@some.domain username:password@smtp.some.domain:995"

PORTAGE_ELOG_MAILFROM: Allows the user to set the "from" address of log mails; defaults to "Portage" if unset.

PORTAGE_ELOG_MAILSUBJECT: Allows the user to create a subject line for log mails. Note that it can make use of two variables: ${PACKAGE} will display the package name and version, while ${HOST} is the fully qualified domain name of the host Portage is running on. For instance:

குறிமுறை Example PORTAGE_ELOG_MAILSUBJECT definition

PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST} with some messages"

முக்கியமானது
Users who used enotice with Portage-2.0.* must completely remove enotice, as it is incompatible with elog.

Portage உள்ளமைவு

முன்பு குறிப்பிட்டது போல், Portage ஐ பல மாறிகளைக் கொண்டு உள்ளமைக்கலாம். இதற்கு அவற்றை /etc/portage/make.conf என்னும் கோப்பிலோ அல்லது /etc/portage/ இடத்தில் உள்ள எதாவதொரு துணை அடைவிலோ வரையறுக்கப்பட வேண்டும். இதைப்பற்றிய கூடுதல் மற்றும் முழு தகவல்களுக்கு make.conf கோப்பையும் Portage ற்கான கைமுறை பக்கத்தையும் காணவும்:

user $

man make.conf

user $man portage

கட்டு-சார்ந்த விருப்பத்தேர்வுகள்

உள்ளமைத்தல் மற்றும் தொகுப்பி விருப்பத்தேர்வுகள்

Portage ஆனது செயலிகளைக் கட்டும்போது, பின்வரும் மாறிகளின் உள்ளடக்கத்தை தொகுப்பியில் செலுத்தி குறுநிரலை உள்ளமைக்கிறது:

CFLAGS மற்றும் CXXFLAGS: C மற்றும் C++ தொகுத்தலுக்கான விரும்பிய தொகுப்பி கொடிகளை வரையறுக்கிறது.
CHOST: செயலியின் உள்ளமைவு குறுநிரலுக்கான கட்டு புரவலன் தகவல்களை வரையறுக்கிறது
MAKEOPTS: இது make கட்டளையில் அளிக்கப்படும். பொதுவாக இது தொகுத்தல் செயலின் போது பயன்படுத்தப்படும் இணை செயல்களின் அளவை வரையறுக்க அமைக்கப்படுகிறது. make கட்டளையின் விருப்பத்தேர்வுகளைப் பற்றிய கூடுதல் தகவல்களை make கைமுறை பக்கத்தில் காணலாம்.

USE மாறியானது உள்ளமைத்தல் மற்றும் தொகுத்தலின் போதும் பயன்படும். இதைபற்றி முழுமையாக முன்புள்ள பாகத்தில் விளக்கி உரைக்கப்பட்டுள்ளது.

ஒன்றாக்குதல் விருப்பத்தேர்வுகள்

Portage ஒரு குறிப்பிட்ட மென்பொருளின் புதிய பதிப்பை நிறுவும்போது அதன் பழைய பதிப்பின் வழக்கொழிந்த கோப்புகளை முறைமையிலிருந்து நீக்கும். இது பழைய பதிப்பை நீக்குவதற்கு முன் பயனருக்கு 5 வினாடி காலக்கெடுவை அளிக்கும். இந்த 5 வினாடி இடைவெளி CLEAN_DELAY மாறியால் தீர்மானிக்கப்படுகிறது.

EMERGE_DEFAULT_OPTS மாறியை அமைப்பதன் மூலம் குறிப்பிட்ட விருப்பத்தேர்வுகளை ஒவ்வொரு முறை இயக்கும்போதும் பின்பற்றுமாறு emerge இடம் தெரிவிக்கலாம். --ask, --verbose, --tree ஆகியவை சில பயனுள்ள விருப்பத்தேர்வுகளாகும்.

உள்ளமைவு கோப்பு பாதுகாப்பு

Portage-பாதுகாக்கப்பட்ட இருப்பிடங்கள்

கோப்புகள் பாதுகாக்கப்பட்ட இடத்தில் சேமிக்கப்படாமல் இருந்தால் Portage மென்பொருளின் புதிய பதிப்பால் அளிக்கப்படும் கோப்புகளை கொண்டு மேலெழுதும். இந்த பாதுகாக்கப்பட்ட இடங்கள் அனைத்தும் CONFIG_PROTECT மாறியில் வரையறுக்கப்பட்டுள்ளது. இவை பெரும்பாலும் உள்ளமைவு கோப்புகளின் இருப்பிடங்களாக இருக்கும். அடைவு பட்டியல் இடைவெளிகளால் பிரிக்கப்பட்டது.

இத்தகைய பாதுகாக்கப்பட்ட இருப்பிடத்தில் எழுதப்படும் கோப்பு மறுபெயரிடப்பட்டு உள்ளமைவு கோப்பின் புதிய பதிப்பு இருப்பதை பற்றிய எச்சரிக்கை பயனருக்கு தெரிவிக்கப்படுகிறது.

இப்போதைய CONFIG_PROTECT அமைப்புகளைப் பற்றி அறிந்துகொள்வதற்கு, emerge --info இன் வெளியீட்டைப் பயன்படுத்தவும்:

user $emerge --info | grep 'CONFIG_PROTECT='

Portage இன் உள்ளமைவு கோப்பு பாதுகாப்பு பற்றிய கூடுதல் தகவல்கள் emerge கைமுறை பக்கத்தில் உள்ள CONFIGURATION FILES பிரிவில் கிடைக்கும்:

user $man emerge

அடைவுகளை தவிர்த்தல்

பாதுகாக்கப்பட்ட இடங்களில் உள்ள சில குறிப்பிட்ட துணை அடைவுகளின் பாதுகாப்பை நீக்க, CONFIG_PROTECT_MASK மாறியைப் பயனர்கள் பயன்படுத்தலாம்.

பதிவிறக்க விருப்பத்தேர்வுகள்

சேவையக இருப்பிடங்கள்

கோரப்பட்ட தகவல் அல்லது தரவு முறைமையில் இல்லையென்றால் இணையத்தில் இருந்து Portage கொணர்ந்து வரும். பல்வேறு தகவல்கள் மற்றும் தரவு அலைதடங்களுக்கான சேவையக இருப்பிடங்கள் பின்வரும் மாறிகளால் வரையறுக்கப்படுகிறது:

GENTOO_MIRRORS: மூலநிரல் கோப்புகளை (distfiles) கொண்டுள்ள சேவையக இருப்பிடங்களின் பட்டியலை வரையறுக்கிறது.
PORTAGE_BINHOST: முறைமைக்கான முன்-கட்டப்பட்ட தொகுப்புகளைக் கொண்டுள்ள குறிப்பிட்ட சேவையக இருப்பிடத்தை வரையறுக்கிறது.

மூன்றாவது அமைப்பானது, பயனர்கள் தங்கள் உள்ளூர் சென்டூ களஞ்சியத்தைப் புதுப்பிக்க பயன்படுத்தும் rsync சேவையகத்தின் இருப்பிடத்தை உள்ளடக்கியது. இது /etc/portage/repos.conf கோப்பில் (அல்லது அடைவினுள் உள்ள கோப்பில்) வரையறுக்கப்படுகிறது:

sync-type: சேவையகத்தின் வகை மற்றும் rsync ற்கான முன்னிருப்புகள் ஆகியவற்றை வரையறுக்கிறது.
sync-uri: சென்டூ கருவூலத்திலிருந்து எடுத்துக் கொண்டு வருவதற்கு Portage பயன்படுத்தும் குறிப்பிட்ட சேவையகத்தை வரையறுக்கிறது.

GENTOO_MIRRORS, sync-type மற்றும் sync-uri மாறிகளை mirrorselect செயலியின் மூலம் தானியக்கமாக அமைக்க இயலும். ஐயத்திற்கு இடமின்றி, இதைப் பயன்படுத்துவதற்கு முன் app-portage/mirrorselect நிறுவப்பட்டிருக்க வேண்டும். மேலும் தகவல்களுக்கு, mirrorselect இன் எழிவரி உதவியைப் பார்க்கவும்:

root #mirrorselect --help

சூழலுக்கு பதிலி சேவையகத்தின் பயன்பாடு தேவைப்பட்டால், http_proxy, ftp_proxy மற்றும் RSYNC_PROXY மாறிகளை அறிவித்துக்கொள்ளலாம்.

Fetch கட்டளைகள்

மூலநிரல் கோப்புகளை எடுத்துக் கொண்டு வருவதற்கு Portage ஆனது wget ஐ இயல்பாகப் பயன்படுத்துகிறது. இதை FETCHCOMMAND மாறி மூலம் மாற்றிக்கொள்ளலாம்.

Portage ஆல், பகுதியளவில் பதிவிறக்கப்பட்ட மூலநிரல் கோப்புகளை மீண்டும் தொடர இயலும். இது இயல்பாக wget ஐ பயன்படுத்துகிறது எனினும் இதை RESUMECOMMAND மாறி மூலம் மாற்றிக்கொள்ளலாம்.

FETCHCOMMAND மற்றும் RESUMECOMMAND மாறிகள் மூலநிரலை சரியான இடத்தில் சேமித்து வைப்பதை உறுதிப்படுத்திக்கொள்ளவும். மாறியினுள் மூலநிரல் இருப்பிடத்தையும் பகிர்நதளிப்பு கோப்புகளின் இருப்பிடத்தையும் அமைப்பதற்கு முறையே \${URI} மற்றும் \${DISTDIR} மாறிகளை பயன்படுத்தலாம்.

FETCHCOMMAND_HTTP, FETCHCOMMAND_FTP, RESUMECOMMAND_HTTP, RESUMECOMMAND_FTP மற்றும் பலவற்றை கொண்டு நெறிமுறை-சார்ந்த கையாளு நிரல்களை வரையறுக்கவும் வாய்ப்புள்ளது.

Rsync அமைப்புகள்

சென்டூ கருவூலத்தை இற்றைப்படுத்த Portage பயன்படுத்தும் rsync கட்டளையை மாற்றியமைக்க வாய்ப்பில்லை என்றாலும் rsync கட்டளைக்கு தொடர்புடைய சில மாறிகளை அமைக்க முடியும்:

PORTAGE_RSYNC_OPTS: ஒத்திசைவின்போது பயன்படுத்தப்படும் முன்னிருப்பு மாறிகளின் எண்ணிக்கையை அமைக்கிறது. ஒவ்வொன்றும் இடைவெளியால் பிரிக்கப்பட்டது. இதைப்பற்றி நன்கு அறிந்தால் மட்டுமே இதை மாற்றியமைக்கவும். PORTAGE_RSYNC_OPTS மாறி வெற்றிடமாக இருந்தால் கூட குறிப்பிட்ட சில விருப்பத்தேர்வுகள் எப்போதும் பயன்படுத்தப்படும் என்பதை நினைவில் கொள்ளவும்.

PORTAGE_RSYNC_EXTRA_OPTS

ஒத்திசைவின் போது கூடுதல் விருப்பத்தேர்வுகளை அமைப்பதற்கு இது பயன்படும். ஒவ்வொரு விருப்பத்தேர்வும் இடைவெளியால் பிரிக்கப்பட்டதாகும்:

--timeout=<எண்>: இது rsync ஒரு தொடர்பானது நேர முடிவு அடைந்துவிட்டது எனக் கருதுவதற்கு முன் எவ்வளவு நேரம் rsync தொடர்பு காத்திருப்பில் இருப்பதற்கான வினாடிகளின் எண்ணிக்கையை வரையறுக்கிறது. இது 180 இல் முன்னிருப்பாக உள்ளது. எனினும் அழைப்புவழி மற்றும் மெதுவாக வேலை செய்யும் கணினிகளைப் பயன்படுத்தும் பயனர்கள் இதை 300 அல்லது அதற்கும் மேல் அமைக்கலாம்.
--exclude-from=/etc/portage/rsync_excludes: இது இற்றைப்படுத்தலின்போது rsync ஆனது தவிர்க்க வேண்டிய தொகுப்புகள் மற்றும்/அல்லது பகுப்புகளின் பட்டியலைக் கொண்டுள்ள கோப்பை சுட்டிக்காட்டுகிறது. இந்த வழக்கில், இது /etc/portage/rsync_excludes ஐ சுட்டிக்காட்டுகிறது.
--quiet: திரையில் வெளிவரும் வெளியீட்டின் அளவை குறைக்கும்.
--verbose: முழு கோப்பு பட்டியலைத் திரையில் அச்சிடும்.
--progress: ஒவ்வொரு கோப்பிற்கான முன்னேற்ற மானியைத் திரையில் காட்டுகிறது.

PORTAGE_RSYNC_RETRIES: இது rsync ஆனது அதிகப்படியாக எத்தனை முறை SYNC மாறியால் அளிக்கப்பட்ட கண்ணாடிதளத்தோடு இணைக்க முயற்சி செய்ய வேண்டும் என்பதை வரையறுக்கிறது. இதன் முன்னருப்பு மதிப்பு 3 முறை.

இந்த விருப்பத்தேர்வுகளைப் பற்றிய மேலும் தகவல்களுக்கு, rsync இன் கைமுறை பக்கத்தைப் படிக்கவும்:

சென்டூ உள்ளமைவு

கிளை தேர்ந்தெடுத்தல்

ACCEPT_KEYWORDS மாறியை கொண்டு முன்னிருப்பு கிளையை மாற்றியமைக்க முடியும். இது முன்னிருப்பாக கட்டமைப்பின் நிலையான கிளையை தேர்வு செய்யும். சென்டூவின் கிளைகளை பற்றிய மேலும் தகவல்களை அடுத்த பகுதியில் காணலாம்.

Portage இன் தனிச்சிறப்புகள்

குறிப்பிட்ட சில portage தனிச்சிறப்புகளை FEATURES மாறியை கொண்டு செயல்படுத்த முடியும். Portage இன் தனிச்சிறப்புகளை பற்றி முந்தைய பகுதியில் ஏற்கனவே விரிவாக எடுத்துரைக்கப்பட்டுள்ளது.

Portage இன் நடத்தை

வள மேலாண்மை

PORTAGE_NICENESS மாறியை கொண்டு பயனர்களால் portage இயக்கத்தின் மென்மை மதிப்பை கூட்டவோ குறைக்கவோ செய்ய இயலும். PORTAGE_NICENESS மதிப்பு இப்போதுள்ள மென்மை மதிப்போடு சேர்க்கப்படும்.

nice மதிப்புகளைப் பற்றிய மேலும் தகவல்களுக்கு, nice இன் கைமுறை பக்கத்தைக் காணவும்:

user $man nice

வெளியீடு நடத்தை

NOCOLOR மாறியானது false மதிப்பை முன்னிருப்பாகக் கொண்டுள்ளது. இது வண்ணமிடப்பட்ட வெளியீட்டைப் பயன்படுத்துவதை Portage முடக்க வேண்டுமா என்பதை வரையறுக்கிறது.

ஒரு கிளையைப் பயன்படுத்துதல்

நிலையான

ACCEPT_KEYWORDS மாறியானது முறைமையில் என்ன மென்பொருள் கிளையைப் பயன்படுத்த வேண்டும் என்பதை வரையறுக்கிறது. இது முன்னிருப்பாக முறைமையின் கட்டமைப்பிற்கான நிலையான மென்பொருள் கிளையைப் பயன்படுத்துகிறது. எடுத்துக்காட்டாக, hppa.

கோப்பு /etc/portage/make.confUsing the stable branch

# The following value is set by default, and does _not_ need explicitly defined.
ACCEPT_KEYWORDS="hppa"

நிலையான கிளையைப் பயன்படுத்தப் பரிந்துரைக்கப்படுகிறது. எனினும், நிலையில்லாத மென்பொருளை இயக்குவதன் மூலம் சென்டூ செயற்றிட்டத்திற்கு உதவ செயலாட்சியர் விரும்பினால், கட்டமைப்பு சோதித்தல் கிளையைப் பயன்படுத்தலாம். எடுத்துக்காட்டாக: ~hppa. எச்சரிக்கையாக இருங்கள், நிலையில்லாத மென்பொருளைப் பயன்படுத்தும்போது சில சிக்கல்கள் ஏற்படலாம், அவ்வாறு எதாவது நேர்ந்தால் வழுவறிக்கையை https://bugs.gentoo.org என்னும் இணையதளத்தில் தாக்கல் செய்ய வேண்டியிருக்கும்.

சோதித்தல்

எச்சரிக்கை
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.

இன்னும் அண்மை மென்பொருளைப் பயன்படுத்த, பயனர்கள் இதற்குப் பதிலாகச் சோதித்தல் கிளையைப் பயன்படுத்துவதைக் கருதலாம். Portage ஐ சோதித்தல் கிளையைப் பயன்படுத்தச் செய்வதற்கு, கட்டமைப்பின் முன் ~ என்னும் குறியைச் சேர்க்கவும்.

கோப்பு /etc/portage/make.confசோதித்தல் கிளையைப் பயன்படுத்துதல்

ACCEPT_KEYWORDS="~hppa"

எடுத்துக்காட்டாக, hppa கட்டமைப்பிற்கான சோதித்தல் கிளையைத் தேர்வு செய்வதற்கு, /etc/portage/make.conf ஐ இவ்வாறு திருத்தியமைக்கவும்:

சோதித்தல் கிளையானது அதன் பெயரில் குறிப்பிட்டுள்ளது போல் சோதித்தலுக்கானதாகும். இதன் பொருள், உருவாக்குநர்கள் இதைச் செயல்படக்கூடியதாகக் கருதினாலும் இன்னும் இது முழுவதுமாக சோதிக்கப்படவில்லை. சோதித்தல் கிளையைப் பயன்படுத்தும் பயனர்கள் இந்த தொகுப்பில் உள்ள வழுவை கண்டுபிடிக்கும் முதல் ஆளாகக்கூட இருக்கலாம். அத்தகைய வழக்கில், இதைப் பற்றி உருவாக்குநர்கள் அறியும் வகையில் ஒரு வழுவறிக்கையை அவர்கள் தாக்கல் செய்ய வேண்டும்.

நிலையான கிளையிலிருந்து சோதித்தல் கிளைக்கு மாற்றும்போது, நிறையத் தொகுப்புகள் இற்றைப்படுத்தப்படுவதைப் பயனர்கள் கண்டறியலாம். நினைவில் வைத்துக் கொள்ளுங்கள், சோதித்தல் கிளைக்கு மாறிய பின், மீண்டும் நிலையான கிளைக்கு மாறுவது அறைகூவலாக இருக்கலாம்.

சோதித்தல் கிளையோடு நிலையான கிளையைக் கலக்குதல்

package.accept_keywords

குறிப்பிட்ட தொகுப்புகளுக்கு மட்டும் சோதித்தல் கிளையை அனுமதித்து மீதமுள்ள முறைமைக்கு நிலையான கிளையைப் பயன்படுத்துமாறு Portage இடம் கேட்டுக்கொள்ள இயலும். இதைச் செய்ய, தொகுப்பின் பகுப்பு மற்றும் பெயரை /etc/portage/package.accept_keywords இல் சேர்க்கவும். இதற்குப் பதிலாக இங்கு ஒரு அடைவை உருவாக்கி (அதே பெயரில்) அந்த அடைவின் கீழுள்ள கோப்பில் தொகுப்பைப் பட்டியலிடவும் வாய்ப்புள்ளது.

எடுத்துக்காட்டாக, gnumeric ற்கான சோதித்தல் கிளையைப் பயன்படுத்த:

கோப்பு /etc/portage/package.accept_keywordsgnumeric செயலிக்கு மட்டும் சோதித்தல் கிளையைப் பயன்படுத்துதல்

app-office/gnumeric

குறிப்பிட்ட பதிப்புகளைச் சோதித்தல்

சோதித்தல் கிளையிலிருந்து ஒரு குறிப்பிட்ட மென்பொருள் பதிப்பைப் பயன்படுத்தி, பின்வரும் பதிப்புகளுக்குச் சோதித்தல் கிளையை Portage பயன்படுத்தாமல் இருக்க, package.accept_keywords இருப்பிடத்தில் பதிப்பைச் சேர்க்கவும். இந்த வழக்கில் = செயற்குறியை பயன்படுத்தவும். மேலும், <=, <, > அல்லது >= செயற்குறிகளை பயன்படுத்திப் பதிப்பின் வரம்பை உள்ளிடலாம்.

எப்படி ஆயினும், பதிப்பு தகவல் சேர்க்கப்பட்டால், செயற்குறியானது கண்டிப்பாக பயன்படுத்தப்பட்டிருக்க வேண்டும். பதிப்பு தகவல் இல்லாமல் செயற்குறியை பயன்படுத்த இயலாது.

பின்வரும் எடுத்துக்காட்டில், சோதித்தல் கிளையிலிருந்தாலும் gnumeric-1.2.13 ஐ நிறுவ அனுமதிக்குமாறு நாம் Portage இடம் கேட்கிறோம்:

கோப்பு /etc/portage/package.accept_keywordsகுறிப்பிட்ட பதிப்பு தேர்ந்தெடுத்தலை அனுமதித்தல்

=app-office/gnumeric-1.2.13

மறைக்கப்பட்ட தொகுப்புகள்

package.unmask

முக்கியமானது
மறையவிழ்தல் தொகுப்புகளின் பயன்பாட்டை சென்டூ உருவாக்குநர்கள் ஆதரிப்பதில்லை. இதைச் செய்யும்போது மிகுந்த எச்சரிக்கையுடன் செயல்படவும். package.unmask மற்றும்/அல்லது package.mask ஆகியவற்றிற்குத் தொடர்புடைய ஆதரவு கோரல்களுக்குப் பதில் அளிக்காமலும் போகலாம்.

ஒரு தொகுப்பானது சென்டூ உருவாக்குநர்களால் மறைக்கப்பட்டு, அதற்கான காரணத்தை package.mask கோப்பில் (இயல்பாக இது /var/db/repos/gentoo/profiles/ என்னும் இடத்தில் இருக்கும்) குறிப்பிட்டிருந்த போதிலும், அந்த தொகுப்பைப் பயனர் பயன்படுத்த விரும்பினால், /etc/portage/package.unmask என்னும் கோப்பில் (இது ஒரு அடைவாக இருப்பின், இந்த அடைவில் உள்ள கோப்பில்) விரும்பிய பதிப்பைச் சேர்க்கவும் (பெரும்பாலும் இது தனியமைப்பில் உள்ள package.mask கோப்பில் இருக்கும் அதே வரியாக இருக்கும்).

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.

எடுத்துக்காட்டாக, =net-mail/hotwayd-0.8 ஆனது மறைக்கப்பட்டிருந்தால், அதே வரியை package.unmask இருப்பிடத்தில் சேர்ப்பதன் மூலம் மறையவிழ்தல் செய்யலாம்:

கோப்பு /etc/portage/package.unmaskஒரு குறிப்பிட்ட தொகுப்பு/பதிப்பை மறையவிழ்தல்

=net-mail/hotwayd-0.8

குறிப்பு
/var/db/repos/gentoo/profiles/package.mask இல் உள்ள பதிவானது தொகுப்பு பதிப்புகளின் வரம்பை உள்ளடக்கியிருந்தால், உண்மையில் தேவைப்படும் பதிப்பு(களை) மட்டும் மறையவிழ்தல் செய்வது இன்றியமையாததாகும். பதிப்புகளை எவ்வாறு குறிப்பிடுவது என்பதைக் கற்றுக்கொள்ள முந்தைய பிரிவைப் படிக்கவும்.

package.mask

குறிப்பிட்ட ஒரு தொகுப்பை அல்லது ஒரு தொகுப்பின் குறிப்பிட்ட ஒரு பதிப்பைக் கணக்கில் எடுத்துக்கொள்ள வேண்டாம் என Portage இடம் கேட்டுக்கொள்ள இயலும். இதைச் செய்ய, தகுந்த வரியை /etc/portage/package.mask இருப்பிடத்தில் (இந்த கோப்பில் அல்லது இந்த அடைவினுள் உள்ள கோப்பில்) சேர்ப்பதன் மூலம் தொகுப்பை மறைக்கலாம்.

எடுத்துக்காட்டாக, gentoo-sources-6.6.13 ஐ விட புதிய கருநிரல் மூலங்களை Portage ஆனது நிறுவுவதைத் தவிர்ப்பதற்கு, பின்வரும் வரியை package.mask இருப்பிடத்தில் சேர்க்கவும்:

கோப்பு /etc/portage/package.mask6.6.13 ஐ விட உயர்ந்த பதிப்பைக் கொண்டுள்ள gentoo-sources ஐ மறைத்தல்

>sys-kernel/gentoo-sources-6.6.13

dispatch-conf

dispatch-conf என்பது ._cfg0000_<name> கோப்புகளை ஒன்றாக்க உதவும் ஒரு கருவியாகும். ._cfg0000_<name> கோப்புகள் CONFIG_PROTECT மாறியால் பாதுகாக்கப்பட்ட அடைவில் உள்ள கோப்பை மேலெழுத Portage விரும்பும்போது இதை உற்பத்தி செய்கிறது.

dispatch-conf மூலம், நிகழும் எல்லா மாற்றங்களைக் கண்காணித்துக் கொண்டே உள்ளமைவு கோப்புகளுக்கான இற்றைப்படுத்தல்களைப் பயனர்களால் ஒன்றாக்க முடியும். dispatch-conf ஆனது உள்ளமைவு கோப்புகளின் இடையில் உள்ள வேறுபாடுகளைத் திட்டுகளாக (patches) அல்லது RCS சீராய்வு முறைமையைப் பயன்படுத்திச் சேமித்து வைக்கிறது. இதன் பொருள், ஒருவேளை உள்ளமைவு கோப்பை இற்றைப்படுத்தும்போது ஒருவர் பிழை செய்துவிட்டால், எந்த நேரத்திலும் நிர்வாகி அந்த கோப்பை அதன் முந்திய பதிப்பிற்கு மாற்றிக் கொள்ளலாம்.

dispatch-conf ஐ பயன்படுத்தும்போது, பயனர்கள் அதனிடம் உள்ளமைவு கோப்பை உள்ளதை உள்ளவாறே வைத்திருக்கவும், புதிய உள்ளமைவு கோப்பை பயன்படுத்தவும், இப்போதைய கோப்பை திருத்தியமைக்கவும் அல்லது மாற்றங்களை ஊடாடல் வழியில் ஒன்றாக்கவும் கேட்டுக்கொள்ளலாம். dispatch-conf ஆனது சில அருமையான கூடுதல் தனிச்சிறப்புகளைக் கொண்டுள்ளது:

கருத்துகளுக்கான இற்றைப்படுத்தல்களை மட்டுமே உள்ளடக்கிய உள்ளமைவு கோப்புகளின் இற்றைப்படுத்தல்களைத் தானியக்கமாக ஒன்றாக்குதல்.
வெள்ளை இடைவெளிகளின் தொகையில் மட்டுமே மாறுபடக்கூடிய உள்ளமைவு கோப்புகளைத் தானியக்கமாக ஒன்றாக்குதல்.

முதலில் /etc/dispatch-conf.conf கோப்பை திருத்தி, archive-dir மாறியால் குறிப்பிடப்பட்ட அடைவு ஒன்றை உருவாக்கவும். பிறகு dispatch-conf ஐ இயக்கவும்:

root #dispatch-conf

dispatch-conf ஐ இயக்கும்போது, ஒரு நேரத்திற்கு ஒன்று என்ற முறையில் ஒவ்வொரு மாற்றப்பட்ட உள்ளமைவு கோப்பையும் திறனாய்வு செய்யலாம். இப்போதைய உள்ளமைவு கோப்பை புதிய ஒன்றைக் கொண்டு இற்றைப்படுத்தி (மாற்றி வைத்து) அடுத்த கோப்பிற்குத் தொடர்ந்து செல்ல u விசையை அழுத்தவும். புதிய கோப்பை முற்றிலும் அழித்து (நீக்கி) அடுத்த கோப்பிற்குத் தொடர்ந்து செல்ல z ஐ அழுத்தவும்.n விசையானது இதைத் தவிர்த்து அடுத்த கோப்பிற்குச் செல்ல dispatch-conf ற்கு கட்டளையிடும். வருங்காலத்திற்கு ஒன்றாக்குதலை தள்ளிப்போடுவதற்கு இதைச் செய்யலாம். எல்லா உள்ளமைவு கோப்புகளையும் பார்த்துக் கொண்ட உடன், dispatch-conf ஆனது வெளியேறும். எந்த நிலையிலும் q விசையை அழுத்தினால் செயலியை விட்டு வெளியேறலாம்.

மேலும் தகவல்களுக்கு, dispatch-conf இன் கைமுறை பக்கத்தைக் காணவும். இது எவ்வாறு ஊடாடும் வகையில் இப்போதைய மற்றும் புதிய உள்ளமைவு கோப்புகளை ஒன்றாக்குவது, புதிய உள்ளமைவு கோப்புகளைத் திருத்துவது, கோப்புகளுக்கு இடையில் உள்ள வேறுபாடுகளை கூர்ந்தாராய்வது போன்றவற்றை விவரிக்கிறது.

user $man dispatch-conf

quickpkg

quickpkg ஐ கொண்டு பயனர்கள் முறைமையில் ஏற்கனவே ஒன்றாக்கப்பட்ட தொகுப்புகளின் காப்பக கோப்புகளை உருவாக்கலாம். இந்த காப்பக கோப்புகளை முன்-கட்டப்பட்ட தொகுப்புகளாகப் பயன்படுத்தலாம். quickpkg ஐ இயக்குவது ஒளிவு மறைவற்ற செயலாகும்: வெறும் தொகுப்புகளின் பெயர்களைக் காப்பக கோப்பில் சேர்க்கும்.

எடுத்துக்காட்டாக, curl, orage மற்றும் procps ஐ காப்பக படுத்த:

root #quickpkg curl orage procps

முன்-கட்டப்பட்ட தொகுப்புகள் $PKGDIR (இயல்பாக /var/cache/binpkgs/) இல் சேமித்து வைக்கப்பட்டிருக்கும். இந்த தொகுப்புகள் $PKGDIR/CATEGORY இல் வைக்கப்பட்டிருக்கும்.

சென்டூ கருவூலத்தின் உட்கணத்தைப் பயன்படுத்துதல்

தொகுப்புகள் மற்றும் பகுப்புகளைத் தவிர்த்து

மற்ற பகுப்புகள்/தொகுப்புகளைத் தவிர்த்து விட்டுக் குறிப்பிட்ட பகுப்புகள்/தொகுப்புகளை மட்டும் தேர்ந்தெடுத்து இற்றைப்படுத்த இயலும். இதை emerge --sync படிநிலையின் போது rsync ஐ குறிப்பிட்ட பகுப்புகள்/தொகுப்புகளைத் தவிர்க்கச் சொல்வதன் மூலம் செய்து முடிக்கலாம்.

இந்த வழிமுறை வேலை செய்வதற்கு, manifest சரிபார்த்தல் முடக்கப்பட்டிருக்க வேண்டும். இது கருவூலத்தின் பாதுகாப்பைக் குறைக்கும். சரிபார்த்தலை முடக்க, sys-apps/portage இல் உள்ள rsync-verify USE கொடியை முடக்கவும் அல்லது சென்டூ கருவூலத்தின் repos.conf பதிவில் sync-rsync-verify-metamanifest=no என அமைக்கவும்.

/etc/portage/make.conf கோப்பில் உள்ள PORTAGE_RSYNC_EXTRA_OPTS மாறியில் தவிர்க்க வேண்டிய சாயல்களை உள்ளடக்கியுள்ள கோப்பின் பெயரை வரையறுக்கவும்:

கோப்பு /etc/portage/make.confதவிர்த்தல் கோப்பை வரையறுத்தல்

PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes"

கோப்பு /etc/portage/rsync_excludesஎல்லா விளையாட்டுக்களையும் தவிர்த்தல்

games-*/*

புதிய, அனுமதிக்கப்பட்ட தொகுப்புகளானது சில புதிய ஆனால் தவிர்க்கப்பட்ட தொகுப்புகளைச் சார்ந்து இருக்கலாம் என்பதால் இது சார்புநிலை சிக்கல்களை விளைவிக்க வாய்ப்புள்ளது என்பதை குறித்துக்கொள்ளவும்.

அதிகாரப்பூர்வமற்ற ebuild களை சேர்த்தல்

தனிப்பயன் ebuild கருவூலத்தை வரையறுத்தல்

Manual creation

சென்டூ ebuild கருவூலம் மூலம் அதிகாரப்பூர்வமாகக் கிடைக்காத ebuild களை பயன்படுத்துமாறு Portage ற்கு அறிவுறுத்த இயலும். இதைச் செய்ய, மூன்றாம் தரப்பு ebuild சேமித்து வைப்பதற்காக ஒரு புதிய அடைவை (எடுத்துக்காட்டாக /var/db/repos/localrepo) உருவாக்கவும். இந்த புதிய கருவூலத்திற்கு அதிகாரப்பூர்வ சென்டூ கருவூலத்தின் அடைவு கட்டமைப்பை ஒத்த அமைப்பு தேவைப்படும்.

root #

mkdir -p /var/db/repos/localrepo/{metadata,profiles}

root #chown -R portage:portage /var/db/repos/localrepo

அடுத்து, கருவூலத்திற்காக நடைமுறைக்கொத்த ஒரு பெயரைத் தேர்ந்தெடுக்கவும். பின்வரும் எடுத்துக்காட்டு "localrepo" என்னும் பெயரைப் பயன்படுத்துகிறது:

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

Tell Portage that the repository master is the main Gentoo ebuild repo, and that the local repository should not be automatically synchronized (as it is not backed by an external source such as an rsync server, git mirror, or other repository type):

கோப்பு /var/db/repos/localrepo/metadata/layout.conf

masters = gentoo
auto-sync = false

Finally, enable the repository on the local system by creating a repository configuration file inside /etc/portage/repos.conf. This will inform Portage of where the custom local repository can be found:

கோப்பு /etc/portage/repos.conf/localrepo.conf

[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.

பல்வேறு மேல்தளமிடுதல்களோடு வேளை செய்தல்

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 கருவூலம்

எடுத்துக்காட்டாக, கடினமாக்கப்பட்ட-உருவாக்கம் மேல்தளமிடுதலை செயல்படுத்த:

root #eselect repository enable hardened-development

இந்த வழிமுறையின் மூலம் சேர்க்கப்பட்ட மேல்தளமிடுதல்களை எளிமையாக இவ்வாறு இற்றைப்படுத்தலாம்:

root #emerge --sync

Portage-அல்லாத பராமரிக்கப்பட்ட மென்பொருள்

தன்-பராமரிக்கப்பட்ட மென்பொருளுடன் Portage ஐ பயன்படுத்துதல்

Sometimes users want to configure, install, and maintain software individually without having Portage automate the process, even though Portage can provide the software titles. Known cases are packages like kernel sources and Nvidia drivers. It is possible to configure Portage so it knows that a certain package is manually installed on the system (and thus take this information into account when calculating dependencies). This process is called injecting and is supported by Portage through the /etc/portage/profile/package.provided file.

எடுத்துக்காட்டாக, கைமுறையாக நிறுவப்படும் gentoo-sources-6.6.13 ஐ பற்றி Portage இடம் தெரிவிப்பதற்கு, பின்வரும் வரியை /etc/portage/profile/package.provided இல் சேர்க்கவும்:

கோப்பு /etc/portage/profile/package.providedgentoo-sources-6.6.13 கைமுறையாக நிறுவப்பட்டுள்ளதாக குறித்தல்

sys-kernel/gentoo-sources-6.6.13

குறிப்பு
இது = என்னும் குறியீடு இல்லாத பதிப்பைப் பயன்படுத்தும் கோப்பாகும்.

முன்னுரை

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.

ஒவ்வொரு தொகுப்பிற்கான சூழல் மாறிகள்

/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.

எடுத்துக்காட்டு: குறிப்பிட்ட தொகுப்புகளுக்காக வழுநீக்குதலைப் பயன்படுத்துதல்

எடுத்துக்காட்டாக, media-video/mplayer தொகுப்பிற்கான வழுநீக்குதலை நாம் செயல்படுத்தலாம்.

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

கோப்பு /etc/portage/env/debug-cflagsவழுநீக்குதலுக்கான குறிப்பிட்ட மாறிகள்

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:

கோப்பு /etc/portage/package.envUse the debug-cflags identifier for the mplayer package

media-video/mplayer debug-cflags

emerge செயல்முறையில் கொக்கியிடுதல்

/etc/portage/bashrc மற்றும் இணைக்கப்பெற்ற கோப்புகளைப் பயன்படுத்துதல்

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).

Portage calls so-called phase hook functions if they are defined in /etc/portage/bashrc. These functions follow the naming convention pre_phase_name and post_phase_name. For example, Portage will call the post_pkg_postinst hook just after calling the pkg_postinst phase function.

To hook in the process, the bash environment can listen to the variables that are always available during ebuild development (such as CATEGORY, P, PF, ...). Based on the values of these variables additional steps and/or functions can be executed.

எடுத்துக்காட்டு: கோப்பு தரவுதளத்தை இற்றைப்படுத்தல்

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 postinst (after installation of files) and postrm (after removal of files) phases, because that is when the files on the file system have been changed.

கோப்பு /etc/portage/bashrcHooking into the postinst and postrm phases

my_database_update() {
    echo ":: Calling aide --update to update its database"
    aide --update
    echo ":: Calling updatedb to update its database"
    updatedb
}
</div>

<div lang="en" dir="ltr" class="mw-content-ltr">
post_pkg_postinst() { my_database_update; }
post_pkg_postrm() { my_database_update; }

--sync க்கு பின் பணிகளை செயல்படுத்துதல்

/etc/portage/postsync.d இருப்பிடத்தை பயன்படுத்துதல்

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.

எடுத்துக்காட்டு: 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.

தனியமைப்பு அமைப்புகளை மேலெழுதல்

/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.

எடுத்துக்காட்டு: nfs-utils ஐ முறைமை தொகுதியில் சேர்த்தல்

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.

இதை செய்ய நாம் தொகுப்பை * ஐ கொண்டு முன்னொட்டு செய்து /etc/portage/profile/packages இல் சேர்க்கலாம்.

கோப்பு /etc/portage/profile/packagesnfs-utils ஐ முறைமை தொகுப்பாக குறித்தல்

*net-fs/nfs-utils

தரமற்ற ஒட்டுகளை இடுதல்

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/

எடுத்துக்காட்டு: 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 hppa Handbook: Working with Portage" overrides earlier display title "கையேடு:HPPA/முழு/Portage".