| 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/cvsroot/gentoo/xml/htdocs/doc/en/handbook/hb-portage-diverttree.xml,v 1.16 2012/07/24 12:12:52 swift Exp $ --> |
| 8 |
|
| 9 |
<sections> |
| 10 |
|
| 11 |
<abstract> |
| 12 |
"Diverting from the Official Tree" gives you some tips and tricks on how to use |
| 13 |
your own Portage tree, how to synchronise only the categories you want, inject |
| 14 |
packages and more. |
| 15 |
</abstract> |
| 16 |
|
| 17 |
<version>3</version> |
| 18 |
<date>2012-11-12</date> |
| 19 |
|
| 20 |
<section> |
| 21 |
<title>Using a Portage Tree Subset</title> |
| 22 |
<subsection> |
| 23 |
<title>Excluding Packages/Categories</title> |
| 24 |
<body> |
| 25 |
|
| 26 |
<p> |
| 27 |
You can selectively update certain categories/packages and ignore the other |
| 28 |
categories/packages. We achieve this by having <c>rsync</c> exclude |
| 29 |
categories/packages during the <c>emerge --sync</c> step. |
| 30 |
</p> |
| 31 |
|
| 32 |
<p> |
| 33 |
You need to define the name of the file that contains the exclude patterns in |
| 34 |
the <c>PORTAGE_RSYNC_EXTRA_OPTS</c> variable in your <path>/etc/portage/make.conf</path>. |
| 35 |
</p> |
| 36 |
|
| 37 |
<pre caption="Defining the exclude file in /etc/portage/make.conf"> |
| 38 |
PORTAGE_RSYNC_EXTRA_OPTS="--exclude-from=/etc/portage/rsync_excludes" |
| 39 |
</pre> |
| 40 |
|
| 41 |
<pre caption="Excluding all games in /etc/portage/rsync_excludes"> |
| 42 |
games-*/* |
| 43 |
</pre> |
| 44 |
|
| 45 |
<p> |
| 46 |
Note however that this may lead to dependency issues since new, allowed packages |
| 47 |
might depend on new but excluded packages. |
| 48 |
</p> |
| 49 |
|
| 50 |
</body> |
| 51 |
</subsection> |
| 52 |
</section> |
| 53 |
<section> |
| 54 |
<title>Adding Unofficial Ebuilds</title> |
| 55 |
<subsection> |
| 56 |
<title>Defining a Portage Overlay Directory</title> |
| 57 |
<body> |
| 58 |
|
| 59 |
<p> |
| 60 |
You can ask Portage to use ebuilds that are not officially available through the |
| 61 |
Portage tree. Create a new directory (for instance |
| 62 |
<path>/usr/local/portage</path>) in which you store the 3rd-party ebuilds. Use |
| 63 |
the same directory structure as the official Portage tree! |
| 64 |
</p> |
| 65 |
|
| 66 |
<p> |
| 67 |
Then define PORTDIR_OVERLAY in <path>/etc/portage/make.conf</path> and have it |
| 68 |
point to the previously defined directory. When you use Portage now, it will |
| 69 |
take those ebuilds into account as well without removing/overwriting those |
| 70 |
ebuilds the next time you run <c>emerge --sync</c>. |
| 71 |
</p> |
| 72 |
|
| 73 |
</body> |
| 74 |
</subsection> |
| 75 |
<subsection> |
| 76 |
<title>Working with Several Overlays</title> |
| 77 |
<body> |
| 78 |
|
| 79 |
<p> |
| 80 |
For the powerusers who develop on several overlays, test packages before they |
| 81 |
hit the Portage tree or just want to use unofficial ebuilds from various |
| 82 |
sources, the <c>app-portage/layman</c> package brings you |
| 83 |
<c>layman</c>, a tool to help you keep the overlay repositories up to date. |
| 84 |
</p> |
| 85 |
|
| 86 |
<p> |
| 87 |
First install and configure <c>layman</c> as shown in the <uri |
| 88 |
link="/proj/en/overlays/userguide.xml">Overlays Users' Guide</uri>, and add your |
| 89 |
desired repositories with <c>layman -a <overlay-name></c>. |
| 90 |
</p> |
| 91 |
|
| 92 |
<p> |
| 93 |
Suppose you have two repositories called <c>java</c> (for the in-development |
| 94 |
java ebuilds) and <c>entapps</c> (for the applications developed in-house for |
| 95 |
your enterprise). You can update those repositories with the following |
| 96 |
command: |
| 97 |
</p> |
| 98 |
|
| 99 |
<pre caption="Using layman to update all repositories"> |
| 100 |
# <i>layman -S</i> |
| 101 |
</pre> |
| 102 |
|
| 103 |
<p> |
| 104 |
For more information on working with overlays, please read <c>man layman</c> and |
| 105 |
the <uri link="/proj/en/overlays/userguide.xml">layman/overlay users' |
| 106 |
guide</uri>. |
| 107 |
</p> |
| 108 |
|
| 109 |
</body> |
| 110 |
</subsection> |
| 111 |
</section> |
| 112 |
<section> |
| 113 |
<title>Non-Portage Maintained Software</title> |
| 114 |
<subsection> |
| 115 |
<title>Using Portage with Self-Maintained Software</title> |
| 116 |
<body> |
| 117 |
|
| 118 |
<p> |
| 119 |
In some cases you want to configure, install and maintain software yourself |
| 120 |
without having Portage automate the process for you, even though Portage |
| 121 |
can provide the software titles. Known cases are kernel sources and nvidia |
| 122 |
drivers. You can configure Portage so it knows that a certain package is |
| 123 |
manually installed on your system. This process is called <e>injecting</e> and |
| 124 |
supported by Portage through the |
| 125 |
<path>/etc/portage/profile/package.provided</path> file. |
| 126 |
</p> |
| 127 |
|
| 128 |
<p> |
| 129 |
For instance, if you want to inform Portage about |
| 130 |
<c>gentoo-sources-2.6.11.6</c> which you've installed manually, add the |
| 131 |
following line to <path>/etc/portage/profile/package.provided</path>: |
| 132 |
</p> |
| 133 |
|
| 134 |
<pre caption="Example line for package.provided"> |
| 135 |
sys-kernel/gentoo-sources-2.6.11.6 |
| 136 |
</pre> |
| 137 |
|
| 138 |
</body> |
| 139 |
</subsection> |
| 140 |
</section> |
| 141 |
</sections> |
Parent Directory
| 
Revision Log