Attachment #101567 for bug #153856

View | Details | Raw Unified | Return to bug 153856 | Differences between
Collapse All | Expand All




<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/handbook/hb-net-advanced.xml,v 1.13 2006/10/28 09:17:55 neysx Exp $ -->

<sections>

<abstract>
Itt arról tanulhatsz hogyan működnek a beállítások - szükséged lesz ezekre az 
ismeretekre mielőtt tovább lépnél a moduláris hálózatok megismerése felé.
</abstract>

<version>7.0</version>
<date>2006-08-30</date>

<section>
<title>Haladó beállítások</title>
<body>

<p>
A <c>config_eth0</c> változó a hálókártya (<c>eth0</c> ebben az esetben) 
beállításának a lelke. Ez egy magas szintű utasításlista a hálózati kártya 
beállítására. A parancsok az utasításlistában egymás után kerülnek 
végrehajtásra.
</p>

<p>
A beépített parancsok listája.
</p>

<table>
<tr>
  <th>Parancs</th>
  <th>Leírás</th>
</tr>
<tr>
  <ti><c>null</c></ti>
  <ti>Nem csinál semmit</ti>
</tr>
<tr>
  <ti><c>noop</c></ti>
  <ti>
    Ha a hálókártya engedélyezett és címe is van, sikeresen lép ki a konfigurálásból
  </ti>
</tr>
<tr>
  <ti>egy IPv4 vagy IPv6 cím</ti>
  <ti>A cím hozzárendelése a hálókártyához</ti>
</tr>
<tr>
  <ti>
    <c>dhcp</c>, <c>adsl</c> vagy <c>apipa</c> (vagy egyedi parancs külső 
forrásból származó modulból)
  </ti>
  <ti>
    Elindítja a parancsot szolgáltató modult. Például a <c>dhcp</c> elindít egy 
    modult amely DHCP-t fog nyújtani. Ez a következők bármelyike lehet: 
    <c>dhcpcd</c>, <c>udhcpc</c>, <c>dhclient</c>, <c>pump</c>.    
  </ti>
</tr>
</table>

<p>
Arra az esetre ha a parancsot nem sikerülne végrehajtani, megadhatsz egy 
tartalék parancsot. Ennek a parancsnak pontosan meg kell egyeznie a 
konfiguráció szerkezetével.
</p>

<p>
Ezekből a parancsokból többet is írhatsz egymás után. Következzen 
néhány gyakorlati példa.
</p>

<pre caption="Beállítási példák">
<comment># Három IPv4 cím hozzárendelése a hálókártyához</comment>
config_eth0=(
  "192.168.0.2/24"
  "192.168.0.3/24"
  "192.168.0.4/24"
)

<comment># Egy IPv4 és két IPv6 cím hozzárendelése a hálókártyához</comment>
config_eth0=(
  "192.168.0.2/24"
  "4321:0:1:2:3:4:567:89ab"
  "4321:0:1:2:3:4:567:89ac"
)

<comment># Hagyjuk, hogy a kernel adjon címet, hacsak a hálókártya 
# le nem áll. Ekkor DHCP-n kérünk új címet. Ha ez nem sikerül az 
# APIPA által meghatározott statikus címet állítjuk be</comment>
config_eth0=(
  "noop"
  "dhcp"
)
fallback_eth0=(
  "null"
  "apipa"
)
</pre>

<note>
Ha egynél több címet rendelsz a hálókártyához az <c>ifconfig</c> modullal,
minden extra címhez generálódik egy újabb név. Azaz a fenti példa esetében 
<c>eth0</c>, <c>eth0:1</c> és <c>eth0:2</c>. Ezekkel semmi különlegeset sem 
tudsz csinálni, mivel a kernel és a többi program is úgy kezeli az 
<c>eth0:1</c>-et és az <c>eth0:2</c>-t mintha <c>eth0</c> volna.
</note>

<impo>
A tartalék parancs sorrendje lényeges! Ha nem adtuk volna meg a <c>null</c> 
opciót, akkor az <c>apipa</c> parancs csak akkor került volna végrehajtásra 
ha a <c>noop</c> parancs végrehajtása nem sikerült volna.
</impo>

<note>
Az <uri link="?part=4&amp;chap=3#apipa">APIPA</uri>-ról és a 
<uri link="?part=4&amp;chap=3#dhcp">DHCP</uri>-ről később lesz szó.
</note>

</body>
</section>
<section>
<title>Hálózati függőségek</title>
<body>

<p>
Az <path>/etc/init.d</path> található initszkriptek függhetnek egy adott 
hálókáryától vagy a hálózattól. Az <path>/etc/conf.d/rc</path> állományban 
található <c>RC_NET_STRICT_CHECKING</c> változóval definiálható az, hogy 
mit értsen a Gentoo <c>hálózat</c> alatt.
</p>

<table>
<tr>
  <th>Érték</th>
  <th>Leírás</th>
</tr>
<tr>
  <ti><c>none</c></ti>
  <ti>A <path>net</path> (hálózat) szolgáltatás állandónak tekintendő</ti>
</tr>
<tr>
  <ti><c>no</c></ti>
  <ti>
    Alapvetően azt jelenti, hogy legalább egy <path>net.*</path> hálózati 
    szolgáltatásnak élnie kell a <path>net.lo</path> mellett. Ezt a beállítást 
    használhatják azok a notebook felhasználók, akik WIFI-vel és állandó 
    hálókártyával is rendelkeznek, de egyszerre csak az egyiket akarják 
    használni.
  </ti>
</tr>
<tr>
  <ti><c>lo</c></ti>
  <ti>
    Megegyezik a <c>no</c> beállítással, de a <path>net.lo</path> is számít. 
    Ez a beállítás azoknak lehet hasznos akiknek nem fontos, hogy 
    rendszeréledés során már működjön a hálózat.
  </ti>
</tr>
<tr>
  <ti><c>yes</c></ti>
  <ti>
    Ezt beállítva az ÖSSZES hálózati kártyának MŰKÖDNIE KELL ahhoz, hogy a 
    <path>hálózat</path> működőképesnek legyen tekinthető.
  </ti>
</tr>
</table>

<p>
Mi a helyzet a <path>net.eth0</path>-tól és a <path>net.eth1</path>-től függő 
<path>net.br0</path>-val? Lehet, hogy a <path>net.eth1</path> egy 
vezetéknélküli vagy PPP eszköz amelyet be kell állítani mielőtt a hídhoz adod. 
Ezt nem lehet megtenni a <path>/etc/init.d/net.br0</path> állományban, mivel ez 
egy szimbólikus link a <path>net.lo</path>-ra.
</p>

<p>
A megoldás az, hogy csinálsz egy saját <c>depend()</c> függvényt az 
<path>/etc/conf.d/net</path> állományban.
</p>

<pre caption="A net.br0 függősége az in /etc/conf.d/net-ben">
<comment># Bármilyen függőséget használhatsz (use, after, before) ahogy azt a 
# szkriptben is láthatod</comment>
depend_br0() {
  need net.eth0 net.eth1
}
</pre>

<p>
A függőségek részletesebb ismertetését megtalálhatod Gentoo Kézikönyv 
<uri link="?part=2&amp;chap=4#doc_chap4">Initszkriptek</uri> című fejezetében.
</p>

</body>
</section>

<section id="variable_name">
<title>A változók nevei és értékei</title>
<body>

<p>
A változók neve több dologból áll össze. Rendesen 
<c>valtozo_${kartya|mac|essid|apmac}</c> alakúak. Például a <c>dhcpcd_eth0</c> 
változó az eth0 dhcpd beállításait tartalmazza és a <c>dhcpcd_essid</c> 
változóban található meg a dhcpd opciói arra az esetre ha bármelyik kártya az 
"essid" ESSID-hez csatlakozik.
</p>

<p>
Azonban nincs semmilyen megkötés arra, hogy a hálókártyák nevének ethx alakúnak 
kell lennie. Valójában a legtöbb vezetéknélküli eszköz neve wlanx, rax vagy 
ethx. Ezen kívül néhány felhasználó által definiált eszköznek, mint amilyenek a 
hidak például, teszőleges név adható, akár kiskutyafule is lehet. Azért, hogy 
még érdekesebb legyen a dolog, a vezetéknélküli elérési pontok (AP, Access 
Point) neve tartalmazhat nem alfanumerikus karaktereket is - ez fontos dolog, 
mivel ESSID alapján tudod beállítani a hálózat paramétereit.
</p>

<p>
A hátránya ennek az, hogy a Gentoo bash változókat használ a hálózathoz - 
és a bash az angolon kívül mást nem ért meg. Ezt úgy kerülhetjük meg, hogy a 
nem angol betűk helyett az aláhúzás <c>_</c> karaktert írjuk.
</p>

<p>
A bash másik hátránya a változók tartalma - néhány karaktert meg kell védeni 
attól, hogy a bash értelmezze őket. Ezt a megvédendő karakter elé írt <c>\</c> 
karakterrel lehet megtenni. A következő karaktereket kell ily módon megvédeni: 
<c>"</c>, <c>'</c> és <c>\</c>.
</p>

<p>
Ebben a példában vezetéknélküli ESSID szerepel, mivel ezekben fordulhatnak elő 
a legváltozatosabb karakterek. Használhatjuk például a <c>My "\ NET</c> 
ESSID-t:
</p>

<pre caption="példa változó nevekre">
<comment># Ez működik, de a domain érvénytelen</comment>
dns_domain_My____NET="My \"\\ NET"

<comment># A fenti sor beállítja a dns domaint My "\ NET-re ha egy 
vezetéknélküli kártya csatlakozik egy My "\ NET ESSID-vel rendelkező elérési 
ponthoz</comment>
</pre>

</body>
</section>
</sections>




<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/handbook/hb-net-start.xml,v 1.7 2006/10/28 09:17:55 neysx Exp $ -->

<sections>

<abstract> 
Ez egy gyors útmutató a hálózati kártyád üzembehelyezéséhez általános 
környezetekben.
</abstract>

<version>7.0</version>
<date>2006-08-30</date>

<section>
<title>Kezdjünk hozzá</title>
<body>

<note>
Ez a leírás feltételezi, hogy már beállítottad a kerneledet és a moduljait a 
hardverednek megfelelően és hogy ismered a kártyád interfész nevét.
Azt is feltételezzük, hogy az <c>eth0</c>-t szeretnéd beállítani, de ez 
<c>eth1</c>, <c>wlan0</c> vagy más is lehet.
</note>

<note>
Ez a leírás a <c>baselayout-1.11.11</c> vagy újabbhoz készült.
</note>

<p>
A hálókártyád beállításának elkezdéséhez először is tudatnod kell a Gentoo RC
rendszerrel, hogy létezik. Ezt úgy teheted meg, hogy az 
<path>/etc/init.d</path> könyvtárban készítesz egy szimbólikus linket amely a 
<path>net.lo</path> fájlról a <path>net.eth0</path>-ra mutat.
</p>

<pre caption="A net.lo-ra mutató szimbólikus link elkészítése">
# <i>cd /etc/init.d</i>
# <i>ln -s net.lo net.eth0</i>
</pre>

<p>
A Gentoo RC rendszere most már tud a hálókártyáról. Tudnia kell még azt is, 
hogy hogyan lehet az új interfészt beállítani. Az <path>/etc/conf.d/net</path> 
fáljban állítható be az összes hálózati interfész. A következő példán láthatod 
hogyan lehet beállítani DHCP-t és fix IP címet.
</p>

<pre caption="Példák az /etc/conf.d/net beállításaira">
<comment># DHCP-hez</comment>
config_eth0=( "dhcp" )

<comment># Statikus IP CIDR formában</comment>
config_eth0=( "192.168.0.7/24" )
routes_eth0=( "default via 192.168.0.1" )

<comment># Statikus IP alhálózati maszkkal megadva</comment>
config_eth0=( "192.168.0.7 netmask 255.255.255.0" )
routes_eth0=( "default gw 192.168.0.1" )
</pre>

<note>
Ha nem állítasz be semmit, akkor a DHCP-t feltételezei a rendszer.
</note>

<note>
A CIDR a Classless InterDomain Routing rövidítése, magyarul talán Osztálymentes 
Domainközi Útvonalválasztásra lehetne fordítani. Eredetileg az IPv4-es címek 
A, B és C osztályokra voltak bontva. Ez a korai osztályozási rendszer nem 
számolt az Internet tömeges elterjedésével és ezért kritikussá vált új, egyedi 
címek kiosztása. A CIDR egy olyan címzési rendszer amely segítsévél egy IP cím 
több IP címet is jelenthet. Egy CIRD Ip cím úgy néz ki mint egy normális IP 
cím, csak a végén található egy per utáni szám, pl. 192.168.0.0/16. A CDIR részletes leírása a 
<uri link="http://rfc.net/rfc1519.html">1519-es számú RFC</uri>-ben található 
meg.
</note>

<p>
Miután beállítottuk a hálókártyát, az alábbi parancsokkal lehet engedélyezni és 
letiltani
</p>

<pre caption="Szkriptek a hálózat elindítására és leállítására">
# <i>/etc/init.d/net.eth0 start</i>
# <i>/etc/init.d/net.eth0 stop</i>
</pre>

<impo>
Ha valami problémába ütközöl, állítsd be az <c>RC_VERBOSE="yes"</c> változót az 
<path>/etc/conf.d/rc</path> állományban és így többet tudhatsz meg arról, 
hogy mi történt.
</impo>

<p>
Miután sikeresen elindítottad és leállítottad a hálózati kártyádat, biztosan 
szeretnéd automatikusan elindítani a Gentoo indításakor. Itt láthatod, hogyan 
lehet ezt megcsinálni. Az utolsó "rc" parancs arra utasítja a Gentoo-t, hogy 
indítson el minden el nem indított szkriptet az aktuális futási szinten.
</p>

<pre caption="Hálókártya automatikus beállítása rendszerindításkor">
# <i>rc-update add net.eth0 default</i>
# <i>rc</i>
</pre>

</body>
</section>

</sections>




<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/handbook/hb-portage-files.xml,v 1.13 2006/11/03 22:03:06 nightmorph Exp $ -->

<sections>

<abstract>
Once you want to know Portage in-depth you need to know where it stores its
files and data.
</abstract>

<version>1.8</version>
<date>2006-11-03</date>

<section>
<title>Portage Files</title>
<subsection>
<title>Configuration Directives</title>
<body>

<p>
Portage comes with a default configuration stored in
<path>/etc/make.globals</path>. When you take a look at it, you'll notice that
all Portage configuration is handled through variables. What variables Portage
listens to and what they mean are described later.
</p>

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

<p>
If you're planning on changing a configuration variable, <e>don't</e> alter
<path>/etc/make.globals</path> or <path>make.defaults</path>. 
Instead use <path>/etc/make.conf</path> which has precedence over
the previous files. You'll also find a <path>/etc/make.conf.example</path>. As 
the name implies, this is merely an example file - Portage does not read in 
this file.
</p>

<p>
You can also define a Portage configuration variable as an environment variable,
but we don't recommend this.
</p>

</body>
</subsection>
<subsection>
<title>Profile-Specific Information</title>
<body>

<p>
We've already encountered the <path>/etc/make.profile</path> directory. Well, 
this isn't exactly a directory but a symbolic link to a profile, by default one
inside <path>/usr/portage/profiles</path> although you can create your own 
profiles elsewhere and point to them. The profile this symlink points to is the
profile to which your system adheres.
</p>

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

</body>
</subsection>
<subsection>
<title>User-Specific Configuration</title>
<body>

<p>
When you need to override Portage's behaviour regarding the installation of
software, you will end up editing files within <path>/etc/portage</path>. You
are <e>highly recommended</e> to use files within <path>/etc/portage</path> and
<e>highly discouraged</e> to override the behaviour through environment
variables!
</p>

<p>
Within <path>/etc/portage</path> you can create the following files:
</p>

<ul>
  <li>
    <path>package.mask</path> which lists the packages you never want Portage to
    install
  </li>
  <li>
    <path>package.unmask</path> which lists the packages you want to be able to
    install even though the Gentoo developers highly discourage you from
    emerging them
  </li>
  <li>
    <path>package.keywords</path> which lists the packages you want to be able
    to install even though the package hasn't been found suitable for your 
    system or architecture (yet)
  </li>
  <li>
    <path>package.use</path> which lists the USE flags you want to use for
    certain packages without having the entire system use those USE flags
  </li>
</ul>

<p>
More information about the <path>/etc/portage</path> directory and a full list
of possible files you can create can be found in the Portage man page:
</p>

<pre caption="Reading the Portage man page">
$ <i>man portage</i>
</pre>

</body>
</subsection>
<subsection>
<title>Changing Portage File &amp; Directory Locations</title>
<body>

<p>
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, Portage tree location, ...
</p>

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

<p>
This document isn't meant to be used as a reference though. If you need 100%
coverage, please consult the Portage and <path>make.conf</path> man pages:
</p>

<pre caption="Reading the Portage and make.conf man pages">
$ <i>man portage</i>
$ <i>man make.conf</i>
</pre>

</body>
</subsection>
</section>
<section>
<title>Storing Files</title>
<subsection>
<title>The Portage Tree</title>
<body>

<p>
The Portage tree default location is <path>/usr/portage</path>. This is defined
by the PORTDIR variable. When you store the Portage tree elsewhere (by altering
this variable), don't forget to change the <path>/etc/make.profile</path>
symbolic link accordingly.
</p>

<p>
If you alter the PORTDIR variable, you might want to alter the following
variables as well since they will not notice the PORTDIR change. This is due to
how Portage handles variables: PKGDIR, DISTDIR, RPMDIR.
</p>

</body>
</subsection>
<subsection>
<title>Prebuilt Binaries</title>
<body>

<p>
Even though Portage doesn't use prebuilt binaries by default, it has extensive
support for them. When you ask Portage to work with prebuilt packages, it will
look for them in <path>/usr/portage/packages</path>. This location is defined by
the PKGDIR variable. 
</p>

</body>
</subsection>
<subsection>
<title>Source Code</title>
<body>

<p>
Application source code is stored in <path>/usr/portage/distfiles</path> by
default. This location is defined by the DISTDIR variable.
</p>

</body>
</subsection>
<subsection>
<title>RPM Files</title>
<body>

<p>
Even though Portage cannot use RPM files, it is able to generate them using the
<c>ebuild</c> command (see <uri link="?part=3&amp;chap=6">The Ebuild
Application</uri>). The default location where Portage stores RPM files is 
<path>/usr/portage/rpm</path> and is defined by the RPMDIR variable.
</p>

</body>
</subsection>
<subsection>
<title>Portage Database</title>
<body>

<p>
Portage stores the state of your system (what packages are installed, what files
belong to which package, ...) in <path>/var/db/pkg</path>. Do <e>not</e> alter
these files manually! It might break Portage's knowledge of your system.
</p>

</body>
</subsection>
<subsection>
<title>Portage Cache</title>
<body>

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

</body>
</subsection>
</section>
<section>
<title>Building Software</title>
<subsection>
<title>Temporary Portage Files</title>
<body>

<p>
Portage's temporary files are stored in <path>/var/tmp</path> by default. This 
is defined by the PORTAGE_TMPDIR variable.
</p>

<p>
If you alter the PORTAGE_TMPDIR variable, you might want to alter the following
variables as well since they will not notice the PORTAGE_TMPDIR change. This 
is due to how Portage handles variables: BUILD_PREFIX.
</p>

</body>
</subsection>
<subsection>
<title>Building Directory</title>
<body>

<p>
Portage creates specific build directories for each package it emerges inside
<path>/var/tmp/portage</path>. This location is defined by the BUILD_PREFIX
variable.
</p>

</body>
</subsection>
<subsection>
<title>Live Filesystem Location</title>
<body>

<p>
By default Portage installs all files on the current filesystem 
(<path>/</path>), but you can change this by setting the ROOT environment 
variable. This is useful when you want to create new build images.
</p>

</body>
</subsection>
</section>
<section>
<title>Logging Features</title>
<subsection>
<title>Ebuild Logging</title>
<body>

<p>
Portage can create per-ebuild logfiles, but only when the PORT_LOGDIR variable
is set to a location that is writable by Portage (the portage user). By default
this variable is unset. If you don't set PORT_LOGDIR, then you won't receive
any build logs with the current logging system, though you may receive some
logs from the new <c>elog</c>. If you do have PORT_LOGDIR defined and you use
elog, you will receive build logs and any logs saved by elog, as explained
below.
</p>

<p>
Portage offers fine-grained control over logging through the use of
<c>elog</c>:
</p>

<ul>
  <li>
    PORTAGE_ELOG_CLASSES: This is where you set what kinds of messages to be
    logged. You can use any space-separated combination of <c>info</c>,
    <c>warn</c>, <c>error</c>, and <c>log</c>.
  </li>
  <li>
    <ul>
      <li>info: Logs "einfo" messages printed by an ebuild</li>
      <li>warn: Logs "ewarn" messages printed by an ebuild</li>
      <li>error: Logs "eerror" messages printed by an ebuild</li>
      <li>log: Logs the "elog" messages found in some ebuilds</li>
    </ul>
  </li>
  <li>
    PORTAGE_ELOG_SYSTEM: This selects the module(s) to process the log
    messages. If left empty, logging is disable. You can use any
    space-separated combination of <c>save</c>, <c>custom</c>, <c>syslog</c>,
    and <c>mail</c>. You must select at least one module in order to use elog.
  </li>
  <li>
    <ul>
      <li>
	save: This saves one log per package in <path>$PORT_LOGDIR/elog</path>,
	or <path>/var/log/portage/elog</path> if $PORT_LOGDIR is not defined.
      </li>
      <li>
	custom: Passes all messages to a user-defined command in
	$PORTAGE_ELOG_COMMAND; this will be discussed later.
      </li>
      <li>syslog: Sends all messages to the installed system logger.</li>
      <li>
	mail: Passes all messages to a user-defined mailserver in
	$PORTAGE_ELOG_MAILURI; this will be discussed later. The mail features
	of elog require &gt;=<c>portage-2.1.1</c>.
      </li>
    </ul>
  </li>
  <li>
    PORTAGE_ELOG_COMMAND: This is only used when the <c>custom</c> module is
    enabled. Here is where you specify a command to process log messages. Note
    that you can make use of two variables: ${PACKAGE} is the package name and
    version, while ${LOGFILE} is the absolute path to the logfile. Here's one
    possible usage:
  </li>
  <li>
    <ul>
      <li>
        PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"
      </li>
    </ul>
  </li>
  <li>
    PORTAGE_ELOG_MAILURI: This contains settings for the <c>mail</c> module
    such as address, user, password, mailserver, and port number. The default
    setting is "root@localhost localhost".
  </li>
  <li>
    Here's an example for an smtp server that requires username and
    password-based authentication on a particular port (the default is port
    25):
  </li>
  <li>
    <ul>
      <li>
	PORTAGE_ELOG_MAILURI="user@some.domain
	username:password@smtp.some.domain:995"
      </li>
    </ul>
  </li>
  <li>
    PORTAGE_ELOG_MAILFROM: Allows you to set the "from" address of log mails;
    defaults to "portage" if unset.
  </li>
  <li>
    PORTAGE_ELOG_MAILSUBJECT: Allows you to create a subject line for log
    mails. Note that you 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.
  </li>
  <li>Here's one possible use:</li>
  <li>
    <ul>
      <li>
	PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST}
	with some messages"
      </li>
    </ul>
  </li>
</ul>

<impo>
If you used <c>enotice</c> with Portage-2.0.*, you must completely remove
enotice, as it is incompatible with elog.
</impo>

</body>
</subsection>
</section>
</sections>




<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE sections SYSTEM "/dtd/book.dtd">

<!-- The content of this document is licensed under the CC-BY-SA license -->
<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->

<!-- $Header: /var/www/www.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/handbook/hb-working-portage.xml,v 1.59 2006/09/04 11:21:06 nightmorph Exp $ -->

<sections>

<version>1.54</version>
<date>2006-09-04</date>

<section>
<title>Üdvözlünk a Portage világában</title>
<body>

<p>
A Portage talán a legnevezetesebb újítása a Gentoo-nak a szoftverkezelés terén. 
Nagyfokú rugalmassága és számtalan jellegzetes képessége okán gyakran a Linuxon 
elérhető legjobb szoftverkezelő eszköznek tekintik. 
</p>

<p>
A Portage teljes egészében <uri link="http://www.python.org">Python</uri>ban
és <uri link="http://www.gnu.org/software/bash">Bash</uri>ban íródott, ezért 
teljesen átlátható a felhasználó számára, mivel mindkettő szkriptnyelv.
</p>

<p>
A legtöbb felhasználó a Portage-t az <e>emerge</e> eszköz segítségével 
használja. Ez a fejezet nem szándékozik az emerge kézikönyv-oldalának másolata 
lenni, az emerge teljes opciólistáját a megfelelő kézikönyv-oldalon fogod 
megtalálni:
</p>

<pre caption="Az emerge kézikönyv-oldalának olvasása">
$ <i>man emerge</i>
</pre>

</body>
</section>
<section>
<title>A Portage fa</title>
<subsection>
<title>Ebuildek</title>
<body>

<p>
Amikor csomagokról beszélünk, gyakran a szoftverek elnevezéseire gondolunk, 
amelyek a Gentoo-felhasználók számára a Portage fán keresztül érhetőek el. A 
Portage fa tulajdonképpen <e>ebuildek</e> gyűjteménye, az <e>ebuild</e> pedig 
olyan fájl, amely minden olyan információt tartalmaz, ami a Portage-nek 
szükséges a szoftverkarbantartáshoz (telepítés, keresés, lekérdezés, ...). Ezek 
az ebuildek alapértelmezésben az <path>/usr/portage</path> könyvtárban vannak.
</p>

<p>
Amikor megkéred a Portage-t, hogy hajtson végre valamilyen szoftverrel 
kapcsolatos feladatot, akkor a rendszereden lévő ebuildeket használja 
kiindulópontként. Ezért nagyon fontos, hogy rendszeresen frissítsd ezeket, így 
a Portage tudni fog minden új szoftverről, biztonsági frissítésről, stb.
</p>

</body>
</subsection>
<subsection>
<title>A Portage fa frissítése</title>
<body>

<p>
A Portage fát rendszerint az <uri link="http://rsync.samba.org/">rsync</uri> 
segítségével frissítjük, ami egy gyors inkrementális fájlátviteli eszköz. A 
frissítés meglehetősen egyszerű, mivel az <c>emerge</c> parancs egy front-endet 
biztosít az rsync-hez:
</p>

<pre caption="A Portage fa frissítése">
# <i>emerge --sync</i>
</pre>

<p>
Ha tűzfal-korlátozások miatt nem tudsz rsync-elni, még mindig frissítheted a 
Portage fát a naponta újragenerált Portage snapshotjaink segítségével. Az 
<c>emerge-webrsync</c> eszköz automatikusan letölti és telepíti a legfrissebb 
snapshotot a gépedre:
</p>

<pre caption=" Az emerge-webrsync futtatása">
# <i>emerge-webrsync</i>
</pre>

</body>
</subsection>
</section>
<section>
<title>A szoftverek karbantartása</title>
<subsection>
<title>Szoftverkeresés</title>
<body>

<p>
Ha a Portage fában szoftvernevekre akarsz keresni, használhatod az 
<c>emerge</c> beépített keresőjét. Alapértelmezésben az <c>emerge --search</c> 
azon csomagok nevét adja vissza, amelyek címében részben vagy egészben 
megtalálható az adott keresési kifejezés.
</p>

<p>
Mondjuk keressünk rá az összes olyan csomagra, amelynek a neve tartalmazza a 
"pdf"-et:
</p>

<pre caption="pdf-nevű csomagok keresése">
$ <i>emerge --search pdf</i>
</pre>

<p>
Ha a csomagleírásokban is akarsz keresni, használd a <c>--searchdesc</c> 
(vagy <c>-S</c>) kapcsolót:
</p>

<pre caption="pdf-vonatkozású csomagok keresése">
$ <i>emerge --searchdesc pdf</i>
</pre>

<p>
A kimenetet megnézve észreveheted, hogy egy csomó információval lát el. Az 
egyes mezők elnevezése magáért beszél, ezért nem merülünk el a magyarázatukban:
</p>

<pre caption="Példa az 'emerge --search' kimenetére">
*  net-print/cups-pdf
      Latest version available: 1.5.2
      Latest version installed: [ Not Installed ]
      Size of downloaded files: 15 kB
      Homepage:    http://cip.physik.uni-wuerzburg.de/~vrbehr/cups-pdf/
      Description: Provides a virtual printer for CUPS to produce PDF files.
      License:     GPL-2
</pre>

</body>
</subsection>
<subsection>
<title>Szoftvertelepítés</title>
<body>

<p>
Ha rábukkantál valamilyen neked tetsző szoftverre, könnnyen telepítheted az 
<c>emerge</c> paranccsal: csak írd utána a csomag nevét. Például a 
<c>gnumeric</c> telepítése így néz ki:
</p>

<pre caption="A gnumeric telepítése">
# <i>emerge gnumeric</i>
</pre>

<p>
Mivel sok alkalmazás egymástól is függ, egy adott szoftvercsomag telepítése 
magával vonhatja több függőségi csomag telepítését is. Emiatt nem kell 
aggódnod, mivel a Portage a függőségeket jól kezeli. Ha látni akarod, hogy mit 
<e>telepítene</e> a Portage egy konkrét csomag függőségeként, használd a 
<c>--pretend</c> kapcsolót. Példa:
</p>

<pre caption="A gnumeric függőségeinek megtekintése">
# <i>emerge --pretend gnumeric</i>
</pre>

<p>
Amikor megkéred a Portage-t, hogy telepítsen egy csomagot, le fogja tölteni a 
szükséges forráskódot az Internetről, és ezt alapértelmezésben az 
<path>/usr/portage/distfiles</path> könyvtárban fogja tárolni. Ezután 
kicsomagolja, lefordítja és telepíti a csomagot. Ha azt akarod, hogy a Portage 
csak letöltse, de ne telepítse a forrást, a <c>--fetchonly</c> kapcsolóval 
használd az <c>emerge</c> parancsot:
</p>

<pre caption="A gnumeric forráskódjának letöltése">
# <i>emerge --fetchonly gnumeric</i>
</pre>

</body>
</subsection>
<subsection>
<title>A telepített csomagok dokumentációjának keresése</title>
<body>

<p>
Sok csomagot saját dokumentációval szállítanak. Néha a <c>doc</c> USE flag 
határozza meg, hogy települjön-e a csomag dokumentációja. A <c>doc</c> USE flag 
meglétét az <c>emerge -vp &lt;csomagnév&gt;</c> paranccsal ellenőrizheted.
</p>

<pre caption="A doc USE flag ellenőrzése">
<comment>(Az alsa-lib persze csak egy példa.)</comment>
# <i>emerge -vp alsa-lib</i>
[ebuild  N    ] media-libs/alsa-lib-1.0.9_rc3  +doc -jack 674 kB
</pre>

<p>
A <c>doc</c> USE flaget engedélyezheted vagy letilthatod, akár globálisan az 
<path>/etc/make.conf</path> fájlban, akár csomagonként az 
<path>/etc/portage/package.use</path> fájlban. Létrehozhatsz egy könyvtárat is 
<path>/etc/portage/package.use</path> néven, és itt felsorolhatod az előbbieket 
egy fájlban (ezen a könyvtáron belül). A 
<uri link="?part=2&amp;chap=2">USE flagek</uri> fejezet részletesen tárgyalja 
ezt a témát.
</p>

<p>
Egy adott telepített csomag dokumentációja általában a csomag nevét viselő 
alkönyvtárban található az <path>/usr/share/doc</path> könyvtáron belül. 
Kilistázhatod az összes telepített fájlt az <c>equery</c> segítségével, ami 
része az <c>app-portage/gentoolkit</c> 
<uri link="/doc/en/gentoolkit.xml">csomagnak</uri>.
</p>

<pre caption="A csomagdokumentáció helyének meghatározása">
# <i>ls -l /usr/share/doc/alsa-lib-1.0.9_rc3</i>
total 28
-rw-r--r--  1 root root  669 May 17 21:54 ChangeLog.gz
-rw-r--r--  1 root root 9373 May 17 21:54 COPYING.gz
drwxr-xr-x  2 root root 8560 May 17 21:54 html
-rw-r--r--  1 root root  196 May 17 21:54 TODO.gz

<comment>(Másik lehetőségként használhatod az equery-t bizonyos fájlok helyének 
meghatározására:)</comment>
# <i>equery files alsa-lib | less</i>
media-libs/alsa-lib-1.0.9_rc3
* Contents of media-libs/alsa-lib-1.0.9_rc3:
/usr
/usr/bin
/usr/bin/alsalisp
<comment>(A kimenetet lerövidítettük)</comment>
</pre>

</body>
</subsection>
<subsection>
<title>Szoftvereltávolítás</title>
<body>

<p>
Ha el akarsz távolítani egy szoftvercsomagot a rendszeredből, használd az 
<c>emerge --unmerge</c> parancsot, ami arra utasítja a Portage-t, hogy 
távolítson el minden, az adott csomag által telepített fájlt a rendszerből, 
<e>kivéve</e> az adott alkalmazás konfigurációs fájljait, ha azokat telepítés 
után módosítottad. A konfigurációs fájlok érintetlenül hagyása lehetővé teszi, 
hogy később folytathasd a munkát az adott csomaggal, ha valaha is úgy döntesz, 
hogy újra telepíted.
</p>

<p>
Azonban <brite>nyomatékosan figyelmeztetünk</brite>: a Portage <e>nem</e> fogja 
ellenőrizni, hogy az eltávolítandó csomag szükséges-e más csomagok számára. 
Mindenesetre olyankor azért figyelmeztet, ha olyan csomagot akarsz 
eltávolítani, ami létfontosságú a rendszer számára, és nélküle összeomolhat az 
egész.
</p>

<pre caption="A gnumeric eltávolítása a rendszerből">
# <i>emerge --unmerge gnumeric</i>
</pre>

<p>
Egy csomag eltávolításakor megmaradnak azok a függőségek, amelyeket 
telepítéskor automatikusan magával hozott. A feleslegessé vált, azaz 
eltávolítható függőségek meghatározáshoz használd az 
<c>emerge</c> <c>--depclean</c> funkcióját. Erről később részletesen fogunk 
beszélni.
</p>

</body>
</subsection>
<subsection>
<title>A rendszer frissítése</title>
<body>

<p>
Ha tökéletes állapotban akarod tartani a rendszeredet (nem is szólva a 
legfrissebb biztonsági frissítésekről), rendszeresen frissíteni kell.  Mivel a 
Portage csak a gépeden lévő Portage fában lévő ebuildeket ellenőrzi, először is 
ezt kell frissíteni. Ha ez megtörtént, frissítheted a rendszeredet az 
<c>emerge --update world</c> paranccsal. Az alábbi példában az <c>--ask</c> 
kapcsolót is használjuk, ami megmondja a Portage-nak, hogy mutassa meg a 
frissítendő csomagok listáját, és kérdezzen rá, hogy akarod-e folytatni a 
frissítést:
</p>

<pre caption="A rendszer frissítése">
# <i>emerge --update --ask world</i>
</pre>

<p>
A Portage ezután megkeresi a telepített csomagok újabb verzióját, azonban csak 
a kifejezetten telepített alkalmazásoknak néz utána, a függőségként települt 
csomagoknak nem. Ha minden egyes csomagot frissíteni szeretnél, használd a 
<c>--deep</c> kapcsolót:
</p>

<pre caption="A teljes rendszer frissítése">
# <i>emerge --update --deep world</i>
</pre>

<p>
Mivel biztonsági frissítések olyan csomagokra is jönnek ki, amelyeket nem 
kifejezetten, hanem csak más programok függőségeként telepítettél, érdemes ezt 
a parancsot időnként lefuttatni.
</p>

<p>
Ha nemrég módosítottad valamelyik 
<uri link="?part=2&amp;chap=2">USE flaget</uri>, érdemes használni a 
<c>--newuse</c> kapcsolót is. Ekkor a Portage ellenőrzi, hogy a módosítás miatt 
szükséges-e új csomagok telepítése, vagy a meglévők újrafordítása:
</p>

<pre caption="Teljes rendszerfrissítés">
# <i>emerge --update --deep --newuse world</i>
</pre>

</body>
</subsection>
<subsection>
<title>Metacsomagok</title>
<body>

<p>
A Portage-ben néhány csomagnak nincs valódi tartalma, hanem csomaggyűjtemények 
telepítésére használatos. Például a <c>kde</c> csomag a teljes KDE környezetet 
telepíti úgy, hogy függőségként különféle KDE-vel kapcsolatos csomagokat húz 
magával.
</p>

<p>
Amennyiben ilyen csomagot akarsz eltávolítani, az <c>emerge --unmerge</c> 
futtatása az adott csomagon nem sok mindent fog csinálni, mivel a függőségek 
ott maradnak a rendszerben.
</p>

<p>
A Portage képes eltávolítani az elárvult függőségeket is, de mivel dinamikus 
függőségi rendszerekről van szó, először mindig végezz teljes 
rendszerfrissítést, beleértve a USE flagek módosítása miatti változásokat is. 
Ezután már futtathatod az <c>emerge --depclean</c> parancsot, amivel az 
elárvult függőségeket tudod eltávolítani. Ha ez megtörtént, újra kell 
fordítanod azokat az alkalmazásokat, amelyek dinamikusan voltak linkelve a most 
eltávolított szoftverekhez, de már nincs szükségük azokra.
</p>

<p>
A fentieket a következő három paranccsal tudod megoldani:
</p>

<pre caption="Az elárvult függőségek eltávolítása">
# <i>emerge --update --deep --newuse world</i>
# <i>emerge --depclean</i>
# <i>revdep-rebuild</i>
</pre>

<p>
A <c>revdep-rebuild</c> a <c>gentoolkit</c> csomag része, tehát előbb ezt 
telepítsd:
</p>

<pre caption="A gentoolkit csomag telepítése">
# <i>emerge gentoolkit</i>
</pre>

</body>
</subsection>
</section>
<section>
<title>Amikor a Portage panaszkodik...</title>
<subsection>
<title>SLOTok, virtuális csomagok (virtuals), ágak (branches), architektúrák és profilok</title>
<body>

<p>
Ahogyan már megállapítottuk, a Portage rendkívül hatékony, és sok olyan 
lehetőséget biztosít, amivel más szoftverkezelő eszközök nem rendelkeznek. 
Ennek jobb megértéséhez nyújt segítséget a következőkben néhány szempont kissé 
részletesebb magyarázata.
</p>

<p>
A Portage lehetővé teszi, hogy egy adott csomagnak többféle verziója is 
létezhessen egyazon rendszeren. Míg más diszribúciók inkább a verziószám 
szerint nevezik el a csomagokat, (mint pl. <c>freetype</c> és 
<c>freetype2</c>), a Portage egy <e>SLOT</e>-nak nevezett technológiát használ. 
Egy-egy ebuild egy bizonyos SLOT-ot deklarál a verziójának megfelelően. 
Különböző SLOT-okkal rendelkező ebuildek létezhetnek együtt egyazon rendszeren, 
például a <c>freetype</c> csomagból van <c>SLOT="1"</c> és <c>SLOT="2"</c> 
jelzésű ebuild.
</p>

<p>
Vannak olyan csomagok is, amelyek ugyanazt a funkciót valósítják meg másképpen. 
Például a <c>metalogd</c>, a <c>sysklogd</c> és a <c>syslog-ng</c> is 
rendszernaplózó program. Azok az alkalmazások, amelyek "egy rendszernaplózó" 
létezését követelik meg, nem függhetnek mondjuk a <c>metalogd</c> csomagtól, 
hiszen a többi rendszernaplózó is éppolyan jó választás lenne. A Portage ezért 
úgynevezett "<e>virtual</e>"-ok (virtuális csomagok) segítségével oldja meg ezt 
a problémát: mindegyik rendszernaplózó beletartozik a <c>virtual/syslog</c>-ba, 
így az alkalmazásoknak már megadható függőségként a <c>virtual/syslog</c>.
</p>

<p>
A szoftverek a Portage fában különböző ágakban (branch) lehetnek. 
Alapértelmezés szerint a rendszered csak olyan csomagokat fogad el, amelyeket a 
Gentoo stabilnak ítél. A legtöbb újonnan benyújtott szoftver először a 
tesztelési ágba kerül, ami azt jelenti, hogy további tesztelésnek kell 
alávetni, mielőtt stabillá nyilváníthatják. Igaz, hogy az ilyen ebuildeket is 
látni fogod a Portage fában, de nem lehet frissíteni rájuk, míg nem kerülnek be 
a stabil ágba.
</p>

<p>
Néhány szoftver csak kevés architektúrára érhető el. Ennek okai többfélék 
lehetnek: vagy nem működik a csomag más architektúrákon, vagy további 
tesztelésre van szükség, vagy a fejlesztő, aki benyújtotta a szoftvert a 
Portage fába, nem tudja ellenőrizni, hogy működik-e különböző architektúrákon.
</p>

<p>
Minden Gentoo-telepítés egy bizonyos <c>profil</c>ba tartozik, ami - egyéb 
információk mellett - azon csomagok listáját tartalmazza, amelyek a rendszer 
normális működéséhez szükségesek.
</p>

</body>
</subsection>
<subsection id="blocked">
<title>Blokkolt csomagok</title>
<body>

<pre caption="A Portage blokkolt csomagokra figyelmeztet (a --pretend kapcsolóval)">
[blocks B     ] mail-mta/ssmtp (is blocking mail-mta/postfix-2.2.2-r1)
</pre>

<pre caption="A Portage blokkolt csomagokra figyelmeztet (a --pretend kapcsoló nélkül)">
!!! Error: the mail-mta/postfix package conflicts with another package.
!!!        both can't be installed on the same system together.
!!!        Please use 'emerge --pretend' to determine blockers. 
</pre>

<p>
Az ebuildek olyan speciális mezőket tartalmaznak, amelyek tájékoztatják a 
Portage-t a függőségeikről. Kétféle függőség létezik: fordítási függőségek, 
amelyeket a <c>DEPEND</c>-ben deklarálnak, és a futásidejű függőségek, amelyek 
az <c>RDEPEND</c>-ben vannak deklarálva. Ha az egyik ilyen függőség egy 
csomagot vagy virtuális csomagot kifejezetten <e>nem</e> kompatibilisnek jelez, 
az blokkolást eredményez.
</p>

<p>
A blokkolás feloldásához választhatod azt a lehetőséget, hogy nem telepíted az 
adott csomagot, vagy pedig azt, hogy előbb eltávolítod az ütköző csomagot. A 
példánál maradva: dönthetsz úgy is, hogy nem telepíted a <c>postfix</c>et, vagy 
úgy is, hogy előbb eltávolítod az <c>ssmtp</c>-t.
</p>

<p>
Az is előfordulhat, hogy két, még ezután telepítendő csomag blokkolja egymást. 
Ebben a ritka esetben előbb rá kell jönnöd, miért kell mindkettőt telepítened. 
Többnyire elég szokott lenni az egyik csomag is. Ha mégsem, akkor arra kérünk, 
küldj hibajelentést a 
<uri link="http://bugs.gentoo.org">Gentoo hibakövető rendszeren</uri> 
keresztül.
</p>

</body>
</subsection>
<subsection id="masked">
<title>Maszkolt csomagok</title>
<body>

<pre caption="A Portage maszkolt csomagokra figyelmeztet">
!!! all ebuilds that could satisfy "bootsplash" have been masked. 
</pre>

<pre caption="A Portage maszkolt csomagokra figyelmeztet - indoklás">
!!! possible candidates are:

- gnome-base/gnome-2.8.0_pre1 (masked by: <i>~x86 keyword</i>)
- lm-sensors/lm-sensors-2.8.7 (masked by: <i>-sparc keyword</i>)
- sys-libs/glibc-2.3.4.20040808 (masked by: <i>-* keyword</i>)
- dev-util/cvsd-1.0.2 (masked by: <i>missing keyword</i>)
- media-video/ati-gatos-4.3.0 (masked by: <i>package.mask</i>)
- sys-libs/glibc-2.3.2-r11 (masked by: <i>profile</i>)
</pre>

<p>
Ha olyan csomagot akarsz telepíteni, ami a rendszeredre nem elérhető, akkor 
ilyen maszkolási hibát jelző üzenetet kapsz. Próbálj meg egy másik alkalmazást 
telepíteni helyette, ami elérhető a rendszeredre, vagy pedig várd meg, amíg a 
csomag elérhető lesz. A maszkolásnak mindig oka van:
</p>

<ul>
  <li>
    <b>~arch kulcsszó/keyword</b> azt jelenti, hogy az alkalmazást még nem 
tesztelték kellőképpen ahhoz, hogy bekerüljön a stabil ágba. Várj néhány napot 
vagy hetet, és próbáld újra.
  </li>
  <li>
    <b>-arch kulcsszó/keyword</b> vagy <b>-* kulcsszó/keyword</b> azt jelenti, 
hogy az alkalmazás nem működik az általad használt architektúrán. Ha úgy 
gondolod, hogy igen, akkor küldj hibajelentést a 
<uri link="http://bugs.gentoo.org">bugzilla</uri> weboldalunkon keresztül..
  </li>
  <li>
    <b>hiányzó kulcsszó/missing keyword</b> azt jelenti, hogy az alkalmazást 
még nem tesztelték az adott architektúrán. Kérd meg az architektúra portolási 
csapatát, hogy teszteljék a csomagot, vagy teszteld te helyettük, és számolj be 
a tapasztalataidról a 
<uri link="http://bugs.gentoo.org">bugzilla</uri> oldalon.
  </li>
  <li>
    <b>package.mask</b> azt jelenti, hogy a csomagot hibásnak, instabilnak vagy 
még rosszabbnak találták, ezért szándékosan jelölték meg úgy, hogy 
"ne használd".
  </li>
  <li>
    <b>profile</b> azt jelenti, hogy a csomag nem felel meg a profilodnak: 
tönkreteheti a rendszert, ha telepíted, vagy egyszerűen nem kompatibilis az 
általad használt profillal.
  </li>
</ul>

</body>
</subsection>
<subsection id="missingdependencies">
<title>Hiányzó függőségek</title>
<body>

<pre caption="A Portage hiányzó függőségekre figyelmeztet">
emerge: there are no ebuilds to satisfy "&gt;=sys-devel/gcc-3.4.2-r4".

!!! Problem with ebuild sys-devel/gcc-3.4.2-r2
!!! Possibly a DEPEND/*DEPEND problem. 
</pre>

<p>
A telepítendő alkalmazás egy másik csomagtól függ, ami viszont nem elérhető a 
rendszeredre. Nézd meg a <uri link="http://bugs.gentoo.org">bugzillán</uri>, 
hogy ismert-e a probléma, és ha nem, jelentsd be. Ilyen hibaüzenet elvileg csak 
akkor adódhat, ha ágakat keversz; ha nem ez a helyzet, akkor hibáról van szó, 
amit érdemes jelezni.
</p>

</body>
</subsection>
<subsection id="ambiguousebuild">
<title>Nem egyértelmű ebuild-név</title>
<body>

<pre caption="A Portage nem egyértelmű ebuild-névre figyelmeztet">
!!! The short ebuild name "aterm" is ambiguous.  Please specify
!!! one of the following fully-qualified ebuild names instead:

    dev-libs/aterm
    x11-terms/aterm
</pre>

<p>
A telepítendő alkalmazás neve több csomag nevének is megfelel, ezért meg kell 
adni a kategória nevét is. A Portage felkínálja a választható formákat.
</p>

</body>
</subsection>
<subsection id="circulardependencies">
<title>Körkörös függőségek</title>
<body>

<pre caption="A Portage körkörös függőségekre figyelmeztet">
!!! Error: circular dependencies: 

ebuild / net-print/cups-1.1.15-r2 depends on ebuild / app-text/ghostscript-7.05.3-r1
ebuild / app-text/ghostscript-7.05.3-r1 depends on ebuild / net-print/cups-1.1.15-r2 
</pre>

<p>
Két (vagy több) csomag, amit telepíteni akarsz, egymástól függ, ezért nem lehet 
őket telepíteni. Ez nagy valószínűséggel a Portage fában lévő hiba. 
Megoldásként egy kis idő múltán sync-elj újra, és próbáld meg újra a 
telepítést. Megnézheted a 
<uri link="http://bugs.gentoo.org">bugzillát</uri> is, hátha már ismert a 
hiba, s ha még nem, ott jelezheted.
</p>

</body>
</subsection>
<subsection id="fetchfailed">
<title>Sikertelen letöltés</title>
<body>

<pre caption="A Portage sikertelen letöltésre figyelmeztet">
!!! Fetch failed for sys-libs/ncurses-5.4-r5, continuing...
<comment>(...)</comment>
!!! Some fetch errors were encountered.  Please see above for details.
</pre>

<p>
A Portage nem tudta letölteni az adott alkalmazás forráskódját, de megpróbálja 
folytatni a többi alkalmazás telepítését (ha többről volt szó). Ezt a hibát 
okozhatja egy olyan tükörszerver, amelyet nem jól szinkronizáltak, vagy az, 
hogy az ebuild nem jó helyre mutat. Az is lehet, hogy a forráskódot tartalmazó 
szerver valamiért épp leállt.
</p>

<p>
Próbáld meg újra egy óra elteltével, és kiderül, fennáll-e még a probléma.
</p>

</body>
</subsection>
<subsection id="profileprotect">
<title>A rendszerprofil védelme</title>
<body>

<pre caption="A Portage profilvédelem alatt álló csomagra figyelmeztet">
!!! Trying to unmerge package(s) in system profile. 'sys-apps/portage'
!!! This could be damaging to your system.
</pre>

<p>
Olyan csomagot akarsz eltávolítani, ami a rendszered alapvető csomagjai közé 
tartozik. A profilban létfontosságúként van felsorolva, ezért nem szabad 
eltávolítani.
</p>

</body>
</subsection>
<subsection id="digesterror">
<title>A kivonat (digest) ellenőrzésének hibája</title>
<body>

<p>
Előfordulhat néha csomagtelepítéskor, hogy a következő üzenettel áll le:
</p>

<pre caption="A kivonat ellenőrzésének hibája">
&gt;&gt;&gt; checking ebuild checksums
!!! Digest verification failed:
</pre>

<p>
Ez annak a jele, hogy valami hibádzik a Portage fában -- gyakran azért, mert 
egy fejlesztő hibát követhetett el, amikor feltöltötte a csomagot a fába.
</p>

<p>
Ha a kivonat (digest)/ellenőrző összeg (checksum) ellenőrzése sikertelen, 
<e>ne</e> próbálj sajátkezűleg új kivonatot készíteni a csomaghoz 
("újradigestelni"). Az <c>ebuild foo digest</c> parancs futtatása nem fogja 
megoldani a problémát, sőt szinte biztosan csak rontani fog a helyzeten!
</p>

<p>
Inkább várj egy-két órát, hogy a Portage fa "beálljon". Valószínűleg azonnal 
észrevették a hibát, de kell egy kis idő, amíg a javítás lefut a fán. Várakozás 
közben nézd meg a <uri link="http://bugs.gentoo.org">Bugzillán</uri>, hogy 
jelezték-e már a problémát. Ha nem, akkor rajta, jelezd te!
</p>

<p>
Ha azt látod, hogy javították a hibát, megpróbálkozhatsz egy újabb 
sync-eléssel, ami után már valószínűleg a javított kivonat lesz a fában.
</p>

<impo>
Ez azonban <e>nem</e> jelenti azt, hogy többször is újraszinkronizálhatod a 
fát! Ahogyan az rsync-irányelvekben is leszögeztük (amit akkor olvashatsz, 
amikor az <c>emerge --sync</c>-et futtatod), azok a felhasználók, akik túl 
gyakran sync-elnek, ki lesznek tiltva! Tényleg jobb várni a következő esedékes 
sync idejéig, nehogy túlterheld az rsync szervereket.
</impo>

</body>
</subsection>
</section>
</sections>

Return to bug 153856

Line 0 Link Here

(-)BGO/handbook/hb-net-advanced.xml (+254 lines)
		1	<?xml version="1.0" encoding="UTF-8"?>
		2	<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
		3
		4	<!-- The content of this document is licensed under the CC-BY-SA license -->
		5	<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
		6
		7	<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/handbook/hb-net-advanced.xml,v 1.13 2006/10/28 09:17:55 neysx Exp $ -->
		8
		9	<sections>
		10
		11	<abstract>
		12	Itt arról tanulhatsz hogyan működnek a beállítások - szükséged lesz ezekre az
		13	ismeretekre mielőtt tovább lépnél a moduláris hálózatok megismerése felé.
		14	</abstract>
		15
		16	<version>7.0</version>
		17	<date>2006-08-30</date>
		18
		19	<section>
		20	<title>Haladó beállítások</title>
		21	<body>
		22
		23	<p>
		24	A <c>config_eth0</c> változó a hálókártya (<c>eth0</c> ebben az esetben)
		25	beállításának a lelke. Ez egy magas szintű utasításlista a hálózati kártya
		26	beállítására. A parancsok az utasításlistában egymás után kerülnek
		27	végrehajtásra.
		28	</p>
		29
		30	<p>
		31	A beépített parancsok listája.
		32	</p>
		33
		34	<table>
		35	<tr>
		36	<th>Parancs</th>
		37	<th>Leírás</th>
		38	</tr>
		39	<tr>
		40	<ti><c>null</c></ti>
		41	<ti>Nem csinál semmit</ti>
		42	</tr>
		43	<tr>
		44	<ti><c>noop</c></ti>
		45	<ti>
		46	Ha a hálókártya engedélyezett és címe is van, sikeresen lép ki a konfigurálásból
		47	</ti>
		48	</tr>
		49	<tr>
		50	<ti>egy IPv4 vagy IPv6 cím</ti>
		51	<ti>A cím hozzárendelése a hálókártyához</ti>
		52	</tr>
		53	<tr>
		54	<ti>
		55	<c>dhcp</c>, <c>adsl</c> vagy <c>apipa</c> (vagy egyedi parancs külső
		56	forrásból származó modulból)
		57	</ti>
		58	<ti>
		59	Elindítja a parancsot szolgáltató modult. Például a <c>dhcp</c> elindít egy
		60	modult amely DHCP-t fog nyújtani. Ez a következők bármelyike lehet:
		61	<c>dhcpcd</c>, <c>udhcpc</c>, <c>dhclient</c>, <c>pump</c>.
		62	</ti>
		63	</tr>
		64	</table>
65
66	<p>
67	Arra az esetre ha a parancsot nem sikerülne végrehajtani, megadhatsz egy
68	tartalék parancsot. Ennek a parancsnak pontosan meg kell egyeznie a
69	konfiguráció szerkezetével.
70	</p>
71
72	<p>
73	Ezekből a parancsokból többet is írhatsz egymás után. Következzen
74	néhány gyakorlati példa.
75	</p>
76
77	<pre caption="Beállítási példák">
78	<comment># Három IPv4 cím hozzárendelése a hálókártyához</comment>
79	config_eth0=(
80	"192.168.0.2/24"
81	"192.168.0.3/24"
82	"192.168.0.4/24"
83	)
84
85	<comment># Egy IPv4 és két IPv6 cím hozzárendelése a hálókártyához</comment>
86	config_eth0=(
87	"192.168.0.2/24"
88	"4321:0:1:2:3:4:567:89ab"
89	"4321:0:1:2:3:4:567:89ac"
90	)
91
92	<comment># Hagyjuk, hogy a kernel adjon címet, hacsak a hálókártya
93	# le nem áll. Ekkor DHCP-n kérünk új címet. Ha ez nem sikerül az
94	# APIPA által meghatározott statikus címet állítjuk be</comment>
95	config_eth0=(
96	"noop"
97	"dhcp"
98	)
99	fallback_eth0=(
100	"null"
101	"apipa"
102	)
103	</pre>
104
105	<note>
106	Ha egynél több címet rendelsz a hálókártyához az <c>ifconfig</c> modullal,
107	minden extra címhez generálódik egy újabb név. Azaz a fenti példa esetében
108	<c>eth0</c>, <c>eth0:1</c> és <c>eth0:2</c>. Ezekkel semmi különlegeset sem
109	tudsz csinálni, mivel a kernel és a többi program is úgy kezeli az
110	<c>eth0:1</c>-et és az <c>eth0:2</c>-t mintha <c>eth0</c> volna.
111	</note>
112
113	<impo>
114	A tartalék parancs sorrendje lényeges! Ha nem adtuk volna meg a <c>null</c>
115	opciót, akkor az <c>apipa</c> parancs csak akkor került volna végrehajtásra
116	ha a <c>noop</c> parancs végrehajtása nem sikerült volna.
117	</impo>
118
119	<note>
120	Az <uri link="?part=4&chap=3#apipa">APIPA</uri>-ról és a
121	<uri link="?part=4&chap=3#dhcp">DHCP</uri>-ről később lesz szó.
122	</note>
123
124	</body>
125	</section>
126	<section>
127	<title>Hálózati függőségek</title>
128	<body>
129
130	<p>
131	Az <path>/etc/init.d</path> található initszkriptek függhetnek egy adott
132	hálókáryától vagy a hálózattól. Az <path>/etc/conf.d/rc</path> állományban
133	található <c>RC_NET_STRICT_CHECKING</c> változóval definiálható az, hogy
134	mit értsen a Gentoo <c>hálózat</c> alatt.
135	</p>
136
137	<table>
138	<tr>
139	<th>Érték</th>
140	<th>Leírás</th>
141	</tr>
142	<tr>
143	<ti><c>none</c></ti>
144	<ti>A <path>net</path> (hálózat) szolgáltatás állandónak tekintendő</ti>
145	</tr>
146	<tr>
147	<ti><c>no</c></ti>
148	<ti>
149	Alapvetően azt jelenti, hogy legalább egy <path>net.*</path> hálózati
150	szolgáltatásnak élnie kell a <path>net.lo</path> mellett. Ezt a beállítást
151	használhatják azok a notebook felhasználók, akik WIFI-vel és állandó
152	hálókártyával is rendelkeznek, de egyszerre csak az egyiket akarják
153	használni.
154	</ti>
155	</tr>
156	<tr>
157	<ti><c>lo</c></ti>
158	<ti>
159	Megegyezik a <c>no</c> beállítással, de a <path>net.lo</path> is számít.
160	Ez a beállítás azoknak lehet hasznos akiknek nem fontos, hogy
161	rendszeréledés során már működjön a hálózat.
162	</ti>
163	</tr>
164	<tr>
165	<ti><c>yes</c></ti>
166	<ti>
167	Ezt beállítva az ÖSSZES hálózati kártyának MŰKÖDNIE KELL ahhoz, hogy a
168	<path>hálózat</path> működőképesnek legyen tekinthető.
169	</ti>
170	</tr>
171	</table>
172
173	<p>
174	Mi a helyzet a <path>net.eth0</path>-tól és a <path>net.eth1</path>-től függő
175	<path>net.br0</path>-val? Lehet, hogy a <path>net.eth1</path> egy
176	vezetéknélküli vagy PPP eszköz amelyet be kell állítani mielőtt a hídhoz adod.
177	Ezt nem lehet megtenni a <path>/etc/init.d/net.br0</path> állományban, mivel ez
178	egy szimbólikus link a <path>net.lo</path>-ra.
179	</p>
180
181	<p>
182	A megoldás az, hogy csinálsz egy saját <c>depend()</c> függvényt az
183	<path>/etc/conf.d/net</path> állományban.
184	</p>
185
186	<pre caption="A net.br0 függősége az in /etc/conf.d/net-ben">
187	<comment># Bármilyen függőséget használhatsz (use, after, before) ahogy azt a
188	# szkriptben is láthatod</comment>
189	depend_br0() {
190	need net.eth0 net.eth1
191	}
192	</pre>
193
194	<p>
195	A függőségek részletesebb ismertetését megtalálhatod Gentoo Kézikönyv
196	<uri link="?part=2&chap=4#doc_chap4">Initszkriptek</uri> című fejezetében.
197	</p>
198
199	</body>
200	</section>
201
202	<section id="variable_name">
203	<title>A változók nevei és értékei</title>
204	<body>
205
206	<p>
207	A változók neve több dologból áll össze. Rendesen
208	<c>valtozo_${kartya\|mac\|essid\|apmac}</c> alakúak. Például a <c>dhcpcd_eth0</c>
209	változó az eth0 dhcpd beállításait tartalmazza és a <c>dhcpcd_essid</c>
210	változóban található meg a dhcpd opciói arra az esetre ha bármelyik kártya az
211	"essid" ESSID-hez csatlakozik.
212	</p>
213
214	<p>
215	Azonban nincs semmilyen megkötés arra, hogy a hálókártyák nevének ethx alakúnak
216	kell lennie. Valójában a legtöbb vezetéknélküli eszköz neve wlanx, rax vagy
217	ethx. Ezen kívül néhány felhasználó által definiált eszköznek, mint amilyenek a
218	hidak például, teszőleges név adható, akár kiskutyafule is lehet. Azért, hogy
219	még érdekesebb legyen a dolog, a vezetéknélküli elérési pontok (AP, Access
220	Point) neve tartalmazhat nem alfanumerikus karaktereket is - ez fontos dolog,
221	mivel ESSID alapján tudod beállítani a hálózat paramétereit.
222	</p>
223
224	<p>
225	A hátránya ennek az, hogy a Gentoo bash változókat használ a hálózathoz -
226	és a bash az angolon kívül mást nem ért meg. Ezt úgy kerülhetjük meg, hogy a
227	nem angol betűk helyett az aláhúzás <c>_</c> karaktert írjuk.
228	</p>
229
230	<p>
231	A bash másik hátránya a változók tartalma - néhány karaktert meg kell védeni
232	attól, hogy a bash értelmezze őket. Ezt a megvédendő karakter elé írt <c>\</c>
233	karakterrel lehet megtenni. A következő karaktereket kell ily módon megvédeni:
234	<c>"</c>, <c>'</c> és <c>\</c>.
235	</p>
236
237	<p>
238	Ebben a példában vezetéknélküli ESSID szerepel, mivel ezekben fordulhatnak elő
239	a legváltozatosabb karakterek. Használhatjuk például a <c>My "\ NET</c>
240	ESSID-t:
241	</p>
242
243	<pre caption="példa változó nevekre">
244	<comment># Ez működik, de a domain érvénytelen</comment>
245	dns_domain_My____NET="My \"\\ NET"
246
247	<comment># A fenti sor beállítja a dns domaint My "\ NET-re ha egy
248	vezetéknélküli kártya csatlakozik egy My "\ NET ESSID-vel rendelkező elérési
249	ponthoz</comment>
250	</pre>
251
252	</body>
253	</section>
254	</sections>

Line 0 Link Here

(-)BGO/handbook/hb-net-start.xml (+113 lines)
		1	<?xml version="1.0" encoding="UTF-8"?>
		2	<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
		3
		4	<!-- The content of this document is licensed under the CC-BY-SA license -->
		5	<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
		6
		7	<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/handbook/hb-net-start.xml,v 1.7 2006/10/28 09:17:55 neysx Exp $ -->
		8
		9	<sections>
		10
		11	<abstract>
		12	Ez egy gyors útmutató a hálózati kártyád üzembehelyezéséhez általános
		13	környezetekben.
		14	</abstract>
		15
		16	<version>7.0</version>
		17	<date>2006-08-30</date>
		18
		19	<section>
		20	<title>Kezdjünk hozzá</title>
		21	<body>
		22
		23	<note>
		24	Ez a leírás feltételezi, hogy már beállítottad a kerneledet és a moduljait a
		25	hardverednek megfelelően és hogy ismered a kártyád interfész nevét.
		26	Azt is feltételezzük, hogy az <c>eth0</c>-t szeretnéd beállítani, de ez
		27	<c>eth1</c>, <c>wlan0</c> vagy más is lehet.
		28	</note>
		29
		30	<note>
		31	Ez a leírás a <c>baselayout-1.11.11</c> vagy újabbhoz készült.
		32	</note>
		33
		34	<p>
		35	A hálókártyád beállításának elkezdéséhez először is tudatnod kell a Gentoo RC
		36	rendszerrel, hogy létezik. Ezt úgy teheted meg, hogy az
		37	<path>/etc/init.d</path> könyvtárban készítesz egy szimbólikus linket amely a
		38	<path>net.lo</path> fájlról a <path>net.eth0</path>-ra mutat.
		39	</p>
		40
		41	<pre caption="A net.lo-ra mutató szimbólikus link elkészítése">
		42	# <i>cd /etc/init.d</i>
		43	# <i>ln -s net.lo net.eth0</i>
		44	</pre>
		45
		46	<p>
		47	A Gentoo RC rendszere most már tud a hálókártyáról. Tudnia kell még azt is,
		48	hogy hogyan lehet az új interfészt beállítani. Az <path>/etc/conf.d/net</path>
		49	fáljban állítható be az összes hálózati interfész. A következő példán láthatod
		50	hogyan lehet beállítani DHCP-t és fix IP címet.
		51	</p>
		52
		53	<pre caption="Példák az /etc/conf.d/net beállításaira">
		54	<comment># DHCP-hez</comment>
		55	config_eth0=( "dhcp" )
		56
		57	<comment># Statikus IP CIDR formában</comment>
		58	config_eth0=( "192.168.0.7/24" )
		59	routes_eth0=( "default via 192.168.0.1" )
		60
		61	<comment># Statikus IP alhálózati maszkkal megadva</comment>
		62	config_eth0=( "192.168.0.7 netmask 255.255.255.0" )
		63	routes_eth0=( "default gw 192.168.0.1" )
		64	</pre>
65
66	<note>
67	Ha nem állítasz be semmit, akkor a DHCP-t feltételezei a rendszer.
68	</note>
69
70	<note>
71	A CIDR a Classless InterDomain Routing rövidítése, magyarul talán Osztálymentes
72	Domainközi Útvonalválasztásra lehetne fordítani. Eredetileg az IPv4-es címek
73	A, B és C osztályokra voltak bontva. Ez a korai osztályozási rendszer nem
74	számolt az Internet tömeges elterjedésével és ezért kritikussá vált új, egyedi
75	címek kiosztása. A CIDR egy olyan címzési rendszer amely segítsévél egy IP cím
76	több IP címet is jelenthet. Egy CIRD Ip cím úgy néz ki mint egy normális IP
77	cím, csak a végén található egy per utáni szám, pl. 192.168.0.0/16. A CDIR részletes leírása a
78	<uri link="http://rfc.net/rfc1519.html">1519-es számú RFC</uri>-ben található
79	meg.
80	</note>
81
82	<p>
83	Miután beállítottuk a hálókártyát, az alábbi parancsokkal lehet engedélyezni és
84	letiltani
85	</p>
86
87	<pre caption="Szkriptek a hálózat elindítására és leállítására">
88	# <i>/etc/init.d/net.eth0 start</i>
89	# <i>/etc/init.d/net.eth0 stop</i>
90	</pre>
91
92	<impo>
93	Ha valami problémába ütközöl, állítsd be az <c>RC_VERBOSE="yes"</c> változót az
94	<path>/etc/conf.d/rc</path> állományban és így többet tudhatsz meg arról,
95	hogy mi történt.
96	</impo>
97
98	<p>
99	Miután sikeresen elindítottad és leállítottad a hálózati kártyádat, biztosan
100	szeretnéd automatikusan elindítani a Gentoo indításakor. Itt láthatod, hogyan
101	lehet ezt megcsinálni. Az utolsó "rc" parancs arra utasítja a Gentoo-t, hogy
102	indítson el minden el nem indított szkriptet az aktuális futási szinten.
103	</p>
104
105	<pre caption="Hálókártya automatikus beállítása rendszerindításkor">
106	# <i>rc-update add net.eth0 default</i>
107	# <i>rc</i>
108	</pre>
109
110	</body>
111	</section>
112
113	</sections>

Line 0 Link Here

(-)BGO/handbook/hb-portage-files.xml (+404 lines)
		1	<?xml version='1.0' encoding='UTF-8'?>
		2	<!DOCTYPE sections SYSTEM "/dtd/book.dtd">
		3
		4	<!-- The content of this document is licensed under the CC-BY-SA license -->
		5	<!-- See http://creativecommons.org/licenses/by-sa/2.5 -->
		6
		7	<!-- $Header: /var/www/viewcvs.gentoo.org/raw_cvs/gentoo/xml/htdocs/doc/en/handbook/hb-portage-files.xml,v 1.13 2006/11/03 22:03:06 nightmorph Exp $ -->
		8
		9	<sections>
		10
		11	<abstract>
		12	Once you want to know Portage in-depth you need to know where it stores its
		13	files and data.
		14	</abstract>
		15
		16	<version>1.8</version>
		17	<date>2006-11-03</date>
		18
		19	<section>
		20	<title>Portage Files</title>
		21	<subsection>
		22	<title>Configuration Directives</title>
		23	<body>
		24
		25	<p>
		26	Portage comes with a default configuration stored in
		27	<path>/etc/make.globals</path>. When you take a look at it, you'll notice that
		28	all Portage configuration is handled through variables. What variables Portage
		29	listens to and what they mean are described later.
		30	</p>
		31
		32	<p>
		33	Since many configuration directives differ between architectures, Portage also
		34	has default configuration files which are part of your profile. Your profile is
		35	pointed to by the <path>/etc/make.profile</path> symlink; Portage'
		36	configurations are set in the <path>make.defaults</path> files of your profile
		37	and all parent profiles. We'll explain more about profiles
		38	and the <path>/etc/make.profile</path> directory later on.
		39	</p>
		40
		41	<p>
		42	If you're planning on changing a configuration variable, <e>don't</e> alter
		43	<path>/etc/make.globals</path> or <path>make.defaults</path>.
		44	Instead use <path>/etc/make.conf</path> which has precedence over
		45	the previous files. You'll also find a <path>/etc/make.conf.example</path>. As
		46	the name implies, this is merely an example file - Portage does not read in
		47	this file.
		48	</p>
		49
		50	<p>
		51	You can also define a Portage configuration variable as an environment variable,
		52	but we don't recommend this.
		53	</p>
		54
		55	</body>
		56	</subsection>
		57	<subsection>
		58	<title>Profile-Specific Information</title>
		59	<body>
		60
		61	<p>
		62	We've already encountered the <path>/etc/make.profile</path> directory. Well,
		63	this isn't exactly a directory but a symbolic link to a profile, by default one
		64	inside <path>/usr/portage/profiles</path> although you can create your own
65	profiles elsewhere and point to them. The profile this symlink points to is the
66	profile to which your system adheres.
67	</p>
68
69	<p>
70	A profile contains architecture-specific information for Portage, such as a
71	list of packages that belong to the system corresponding with that profile,
72	a list of packages that don't work (or are masked-out) for that profile, etc.
73	</p>
74
75	</body>
76	</subsection>
77	<subsection>
78	<title>User-Specific Configuration</title>
79	<body>
80
81	<p>
82	When you need to override Portage's behaviour regarding the installation of
83	software, you will end up editing files within <path>/etc/portage</path>. You
84	are <e>highly recommended</e> to use files within <path>/etc/portage</path> and
85	<e>highly discouraged</e> to override the behaviour through environment
86	variables!
87	</p>
88
89	<p>
90	Within <path>/etc/portage</path> you can create the following files:
91	</p>
92
93	<ul>
94	<li>
95	<path>package.mask</path> which lists the packages you never want Portage to
96	install
97	</li>
98	<li>
99	<path>package.unmask</path> which lists the packages you want to be able to
100	install even though the Gentoo developers highly discourage you from
101	emerging them
102	</li>
103	<li>
104	<path>package.keywords</path> which lists the packages you want to be able
105	to install even though the package hasn't been found suitable for your
106	system or architecture (yet)
107	</li>
108	<li>
109	<path>package.use</path> which lists the USE flags you want to use for
110	certain packages without having the entire system use those USE flags
111	</li>
112	</ul>
113
114	<p>
115	More information about the <path>/etc/portage</path> directory and a full list
116	of possible files you can create can be found in the Portage man page:
117	</p>
118
119	<pre caption="Reading the Portage man page">
120	$ <i>man portage</i>
121	</pre>
122
123	</body>
124	</subsection>
125	<subsection>
126	<title>Changing Portage File & Directory Locations</title>
127	<body>
128
129	<p>
130	The previously mentioned configuration files cannot be stored elsewhere -
131	Portage will always look for those configuration files at those exact locations.
132	However, Portage uses many other locations for various purposes: build
133	directory, source code storage, Portage tree location, ...
134	</p>
135
136	<p>
137	All these purposes have well-known default locations but can be altered to your
138	own taste through <path>/etc/make.conf</path>. The rest of this chapter explains
139	what special-purpose locations Portage uses and how to alter their placement on
140	your filesystem.
141	</p>
142
143	<p>
144	This document isn't meant to be used as a reference though. If you need 100%
145	coverage, please consult the Portage and <path>make.conf</path> man pages:
146	</p>
147
148	<pre caption="Reading the Portage and make.conf man pages">
149	$ <i>man portage</i>
150	$ <i>man make.conf</i>
151	</pre>
152
153	</body>
154	</subsection>
155	</section>
156	<section>
157	<title>Storing Files</title>
158	<subsection>
159	<title>The Portage Tree</title>
160	<body>
161
162	<p>
163	The Portage tree default location is <path>/usr/portage</path>. This is defined
164	by the PORTDIR variable. When you store the Portage tree elsewhere (by altering
165	this variable), don't forget to change the <path>/etc/make.profile</path>
166	symbolic link accordingly.
167	</p>
168
169	<p>
170	If you alter the PORTDIR variable, you might want to alter the following
171	variables as well since they will not notice the PORTDIR change. This is due to
172	how Portage handles variables: PKGDIR, DISTDIR, RPMDIR.
173	</p>
174
175	</body>
176	</subsection>
177	<subsection>
178	<title>Prebuilt Binaries</title>
179	<body>
180
181	<p>
182	Even though Portage doesn't use prebuilt binaries by default, it has extensive
183	support for them. When you ask Portage to work with prebuilt packages, it will
184	look for them in <path>/usr/portage/packages</path>. This location is defined by
185	the PKGDIR variable.
186	</p>
187
188	</body>
189	</subsection>
190	<subsection>
191	<title>Source Code</title>
192	<body>
193
194	<p>
195	Application source code is stored in <path>/usr/portage/distfiles</path> by
196	default. This location is defined by the DISTDIR variable.
197	</p>
198
199	</body>
200	</subsection>
201	<subsection>
202	<title>RPM Files</title>
203	<body>
204
205	<p>
206	Even though Portage cannot use RPM files, it is able to generate them using the
207	<c>ebuild</c> command (see <uri link="?part=3&chap=6">The Ebuild
208	Application</uri>). The default location where Portage stores RPM files is
209	<path>/usr/portage/rpm</path> and is defined by the RPMDIR variable.
210	</p>
211
212	</body>
213	</subsection>
214	<subsection>
215	<title>Portage Database</title>
216	<body>
217
218	<p>
219	Portage stores the state of your system (what packages are installed, what files
220	belong to which package, ...) in <path>/var/db/pkg</path>. Do <e>not</e> alter
221	these files manually! It might break Portage's knowledge of your system.
222	</p>
223
224	</body>
225	</subsection>
226	<subsection>
227	<title>Portage Cache</title>
228	<body>
229
230	<p>
231	The Portage cache (with modification times, virtuals, dependency tree
232	information, ...) is stored in <path>/var/cache/edb</path>. This location really
233	is a cache: you can clean it if you are not running any portage-related
234	application at that moment.
235	</p>
236
237	</body>
238	</subsection>
239	</section>
240	<section>
241	<title>Building Software</title>
242	<subsection>
243	<title>Temporary Portage Files</title>
244	<body>
245
246	<p>
247	Portage's temporary files are stored in <path>/var/tmp</path> by default. This
248	is defined by the PORTAGE_TMPDIR variable.
249	</p>
250
251	<p>
252	If you alter the PORTAGE_TMPDIR variable, you might want to alter the following
253	variables as well since they will not notice the PORTAGE_TMPDIR change. This
254	is due to how Portage handles variables: BUILD_PREFIX.
255	</p>
256
257	</body>
258	</subsection>
259	<subsection>
260	<title>Building Directory</title>
261	<body>
262
263	<p>
264	Portage creates specific build directories for each package it emerges inside
265	<path>/var/tmp/portage</path>. This location is defined by the BUILD_PREFIX
266	variable.
267	</p>
268
269	</body>
270	</subsection>
271	<subsection>
272	<title>Live Filesystem Location</title>
273	<body>
274
275	<p>
276	By default Portage installs all files on the current filesystem
277	(<path>/</path>), but you can change this by setting the ROOT environment
278	variable. This is useful when you want to create new build images.
279	</p>
280
281	</body>
282	</subsection>
283	</section>
284	<section>
285	<title>Logging Features</title>
286	<subsection>
287	<title>Ebuild Logging</title>
288	<body>
289
290	<p>
291	Portage can create per-ebuild logfiles, but only when the PORT_LOGDIR variable
292	is set to a location that is writable by Portage (the portage user). By default
293	this variable is unset. If you don't set PORT_LOGDIR, then you won't receive
294	any build logs with the current logging system, though you may receive some
295	logs from the new <c>elog</c>. If you do have PORT_LOGDIR defined and you use
296	elog, you will receive build logs and any logs saved by elog, as explained
297	below.
298	</p>
299
300	<p>
301	Portage offers fine-grained control over logging through the use of
302	<c>elog</c>:
303	</p>
304
305	<ul>
306	<li>
307	PORTAGE_ELOG_CLASSES: This is where you set what kinds of messages to be
308	logged. You can use any space-separated combination of <c>info</c>,
309	<c>warn</c>, <c>error</c>, and <c>log</c>.
310	</li>
311	<li>
312	<ul>
313	<li>info: Logs "einfo" messages printed by an ebuild</li>
314	<li>warn: Logs "ewarn" messages printed by an ebuild</li>
315	<li>error: Logs "eerror" messages printed by an ebuild</li>
316	<li>log: Logs the "elog" messages found in some ebuilds</li>
317	</ul>
318	</li>
319	<li>
320	PORTAGE_ELOG_SYSTEM: This selects the module(s) to process the log
321	messages. If left empty, logging is disable. You can use any
322	space-separated combination of <c>save</c>, <c>custom</c>, <c>syslog</c>,
323	and <c>mail</c>. You must select at least one module in order to use elog.
324	</li>
325	<li>
326	<ul>
327	<li>
328	save: This saves one log per package in <path>$PORT_LOGDIR/elog</path>,
329	or <path>/var/log/portage/elog</path> if $PORT_LOGDIR is not defined.
330	</li>
331	<li>
332	custom: Passes all messages to a user-defined command in
333	$PORTAGE_ELOG_COMMAND; this will be discussed later.
334	</li>
335	<li>syslog: Sends all messages to the installed system logger.</li>
336	<li>
337	mail: Passes all messages to a user-defined mailserver in
338	$PORTAGE_ELOG_MAILURI; this will be discussed later. The mail features
339	of elog require >=<c>portage-2.1.1</c>.
340	</li>
341	</ul>
342	</li>
343	<li>
344	PORTAGE_ELOG_COMMAND: This is only used when the <c>custom</c> module is
345	enabled. Here is where you specify a command to process log messages. Note
346	that you can make use of two variables: ${PACKAGE} is the package name and
347	version, while ${LOGFILE} is the absolute path to the logfile. Here's one
348	possible usage:
349	</li>
350	<li>
351	<ul>
352	<li>
353	PORTAGE_ELOG_COMMAND="/path/to/logger -p '\${PACKAGE}' -f '\${LOGFILE}'"
354	</li>
355	</ul>
356	</li>
357	<li>
358	PORTAGE_ELOG_MAILURI: This contains settings for the <c>mail</c> module
359	such as address, user, password, mailserver, and port number. The default
360	setting is "root@localhost localhost".
361	</li>
362	<li>
363	Here's an example for an smtp server that requires username and
364	password-based authentication on a particular port (the default is port
365	25):
366	</li>
367	<li>
368	<ul>
369	<li>
370	PORTAGE_ELOG_MAILURI="user@some.domain
371	username:password@smtp.some.domain:995"
372	</li>
373	</ul>
374	</li>
375	<li>
376	PORTAGE_ELOG_MAILFROM: Allows you to set the "from" address of log mails;
377	defaults to "portage" if unset.
378	</li>
379	<li>
380	PORTAGE_ELOG_MAILSUBJECT: Allows you to create a subject line for log
381	mails. Note that you can make use of two variables: ${PACKAGE} will display
382	the package name and version, while ${HOST} is the fully qualified domain
383	name of the host Portage is running on.
384	</li>
385	<li>Here's one possible use:</li>
386	<li>
387	<ul>
388	<li>
389	PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} was merged on \${HOST}
390	with some messages"
391	</li>
392	</ul>
393	</li>
394	</ul>
395
396	<impo>
397	If you used <c>enotice</c> with Portage-2.0.*, you must completely remove
398	enotice, as it is incompatible with elog.
399	</impo>
400
401	</body>
402	</subsection>
403	</section>
404	</sections>