aboutsummaryrefslogtreecommitdiff
path: root/doc/faq/operation.html.part
blob: b408f6ff8fc6dd8cc5436515f317000c498f21d3 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
<!-- vim: set tw=120 ft=html sw=4 sts=4 et : -->

<h1>FAQ: Operation</h1>

<ul>
    <li><a href="operation.html#updatingdepends">Paludis does not update DEPENDs of already installed packages</a></li>
    <li><a href="operation.html#updateworldmissesthings">Updating world misses things</a></li>
    <li><a href="operation.html#info">Get package information for a bug report</a></li>
    <li><a href="operation.html#arrows">What do those fancy arrows when merging things mean?</a></li>
    <li><a href="operation.html#updates">Profiles Updates for Package Moves and Slot Moves</a></li>
</ul>

<h2 id="updatingdepends">Paludis does not update DEPENDs of already installed packages</h2>

<p>Paludis ignores build time dependencies (DEPENDs) of already installed packages by default.
If you need a different behaviour, use the <code>--dl-installed-deps-pre</code>
option. You may also want to use the <code>everything</code> set rather than
<code>world</code>.</p>

<h2 id="updateworldmissesthings">Updating world misses things</h2>

<p>Paludis doesn't 'miss' packages. If you think it is missing something, check the
following:</p>

<ul>
    <li>See the previous item. Is the thing in question only included as a build dependency of
    a package?</li>
    <li>Are you sure the package is in world? <code>paludis --query world</code> will tell
    you.</li>
    <li>Is the upgrade being blocked by another package that depends upon a lower version
    of the thing being missed?</li>
</ul>

<h2 id="info">Get package information for a bug report</h2>

<p>Use <code>paludis --info</code> to get general configuration information. Paludis will <em>not</em> show any
configuration that is 'per-package' in this output. (This is different to <code>emerge</code>, which misleadingly shows
an arbitrary global configuration no matter what.)</p>

<p>If you are submitting a bug report for a particular package, use <code>paludis --info <em>spec</em></code> instead.
If it's an installed package, <em>spec</em> can usually just be the qualified package name (for example, <code>paludis
    --info sys-apps/paludis</code>). If you're installing a package, you should instead specify an exact package ID
(such as <code>paludis --info =sys-apps/paludis-0.26.0_alpha12::paludis-overlay</code>).</p>

<h2 id="arrows">What do those fancy arrows when merging things mean?</h2>

<p>They tell how each file is merged to root. They consist of three parts:</p>

<ul>
    <li>The first part talks about what happened to the entry this one is replacing (if any):
    <dl>
        <dt><code>&gt;</code></dt>
        <dd>The entry didn't exist</dd>
        <dt><code>=</code></dt>
        <dd>The entry was reused</dd>
        <dt><code>&lt;</code></dt>
        <dd>The entry was unlinked</dd>
    </dl></li>
    <li>The second part refers to how it was merged:
    <dl>
        <dt><code>&gt;</code></dt>
        <dd>This entry was copied</dd>
        <dt><code>-</code></dt>
        <dd>Merged using <code>rename()</code></dd>
        <dt><code>^</code></dt>
        <dd>Merged by using <code>rename()</code> on a parent directory</dd>
        <dt><code>&amp;</code></dt>
        <dd>Merged as a hardlink</dd>
    </dl></li>
    <li>The third part refers to permissions and modes:
    <dl>
        <dt><code>&gt;</code></dt>
        <dd>Nothing done</dd>
        <dt><code>~</code></dt>
        <dd>Fixed ownership</dd>
        <dt><code>*</code></dt>
        <dd>Added set*id bits</dd>
        <dt><code>+</code></dt>
        <dd>Copied xattrs</dd>
    </dl></li>
</ul>

<h2 id="updates">Profiles Updates for Package Moves and Slot Moves</h2>

<p>Gentoo includes support for repositories specifying that a package has moved (e.g. <code>app-misc/foo</code> is now
called <code>app-admin/foo</code>) or changed slot (e.g. <code>app-misc/foo:0</code> is now
<code>app-misc/foo:2</code>). Paludis has experimental support for performing these updates after a sync, but by default
updates are not carried out.</p>

<p><strong>Carrying out updates is not guaranteed to work. Before allowing Paludis to carry out updates, you should back
    up your VDB. If you don't know what this means, wait until updates have received wider testing. If you don't have a
    backup of your VDB and things do go wrong, you will have to do a full system reinstall to fix things.</strong></p>

<p>If you fully understand the above paragraph, you can set the <code>PALUDIS_CARRY_OUT_UPDATES</code> environment
variable to <code>yes</code> and then sync to perform updates.</p>

<p>Sometimes it is possible for renames to cause collisions. For example, if <code>foo</code> is being renamed to
<code>bar</code>, and you have both <code>foo</code> and <code>bar</code> installed, Paludis will be unable to perform
the update. In this situation, you should generally manually uninstall the older of <code>foo</code> or
<code>bar</code>.</p>