| 1 |
On Sat, 23 May 2009 19:08:50 -0300 |
| 2 |
Jorge Morais <please.no.spam.here@×××××.com> wrote: |
| 3 |
|
| 4 |
> One idea: you can can recompile python with a safe |
| 5 |
> prefix (such as a subdir of your home), issue make install (not as root, |
| 6 |
> for increased safety) and see where Python install its files relative to |
| 7 |
> the prefix, so you can delete them from your system |
| 8 |
> (to be more careful before deleting a file, you can issue |
| 9 |
> qfile <FILE> to see if it is owned by a portage-installed package. |
| 10 |
> And in the end you can emerge python properly, from the sources, so all |
| 11 |
> the ebuild logic (which is more than just ./configure, make and make install) |
| 12 |
> gets applied, and you get a Python installation that respects your USE flags, |
| 13 |
> CFLAGS and other system-specific settings (obviously you don't get such a |
| 14 |
> system-customized python when you use the binary package from tinderbox). |
| 15 |
> |
| 16 |
|
| 17 |
I should mention that you should be careful about deleting any files - |
| 18 |
and qfile is not a 100% guarantee that the file does not come from a |
| 19 |
Portage-installed package. For example, in my system Python was |
| 20 |
installed by Portage, and |
| 21 |
$ file /usr/bin/python |
| 22 |
/usr/bin/python: symbolic link to `python2.5' |
| 23 |
, yet |
| 24 |
$ qfile /usr/bin/python |
| 25 |
<No output> |
| 26 |
|
| 27 |
So qfile giving an empty output is not a guarantee that the file is |
| 28 |
indeed orphan. Specially with symlinks - look at the Python ebuild |
| 29 |
and see the way these symlinks are generated. |
| 30 |
|
| 31 |
And of course, it is wise to emerge --buildpkg python before doing any |
| 32 |
cleaning. |
| 33 |
And after the cleaning, reemerge Python. |
| 34 |
|
| 35 |
Regards, |
| 36 |
Jorge |
Archives