| 1 |
"Christopher E" <sensory.access@×××××.com> posted |
| 2 |
184c54640605121544p28ea1f55j84bacf952d2f2af8@××××××××××.com, excerpted |
| 3 |
below, on Fri, 12 May 2006 18:44:23 -0400: |
| 4 |
|
| 5 |
> One more sample, this one seems to only add one pices of info that most of |
| 6 |
> not copyed when trying the first time: |
| 7 |
> |
| 8 |
> libtool: link: warning: |
| 9 |
> `/usr/lib/gcc/x86_64-pc-linux-gnu/3.4.6/../../..//libxml2.la' seems to be |
| 10 |
> moved |
| 11 |
|
| 12 |
As everyone says, don't worry about it. It's the way portage does things. |
| 13 |
|
| 14 |
More specifically, portage installs to a fake root, using sandbox to |
| 15 |
protect the real working system, then moves the entire package from the |
| 16 |
fake root to the real one all at the same time. One of the benefits of |
| 17 |
this is that it's only for a very small period of time that part of the |
| 18 |
package is the old one and part the new. Thus, it's easier to keep |
| 19 |
running stuff as one normally would, undisturbed, using the old version |
| 20 |
until the new one is ready to move over (the ebuild qmerge step), then the |
| 21 |
new one, instead of part of one and part of the other while things are |
| 22 |
still building. Another benefit is that it's far easier to keep track of |
| 23 |
exactly what a package installs, and to wrap it up as a binary package |
| 24 |
(using FEATURES=buildpkg, very handy to have around as a backup!), thus |
| 25 |
allowing portage to cleanly unmerge the package when done with it, as well |
| 26 |
as having a binary package that works. |
| 27 |
|
| 28 |
As part of this process, it sets up pointers to the files and dependencies |
| 29 |
where they will be when everything is done. However, since it's in the |
| 30 |
fake root while it's doing this, it can't see the dependencies at the |
| 31 |
place the make file said they were supposed to be, so it warns that they |
| 32 |
seem to be moved. The issue WOULD be a bit of a problem if they were |
| 33 |
working on the live system at that point, certainly something to warn |
| 34 |
about, but since they are in the fake root not the live system at that |
| 35 |
point, it's expected that they can't find the things they are warning |
| 36 |
about, because they are set up not to find them at that point, but so it |
| 37 |
will all work once everything is moved to the live system in the qmerge |
| 38 |
step. |
| 39 |
|
| 40 |
To learn more about the other steps taken by the helper ebuild script that |
| 41 |
emerge calls for each package it merges, what each one does, how those |
| 42 |
relate to the various procedures one often finds in an ebuild, etc, try |
| 43 |
the ebuild manpages, both man 1 ebuild and man 5 ebuild. You should have |
| 44 |
either read previously, or read at the same time, the working with portage |
| 45 |
section of the Gentoo Handbook. It's really amazing to see how it all |
| 46 |
fits together, once you start to get the picture. |
| 47 |
|
| 48 |
|
| 49 |
|
| 50 |
-- |
| 51 |
Duncan - List replies preferred. No HTML msgs. |
| 52 |
"Every nonfree program has a lord, a master -- |
| 53 |
and if you use the program, he is your master." Richard Stallman |
| 54 |
|
| 55 |
-- |
| 56 |
gentoo-amd64@g.o mailing list |
Archives