| 1 |
> Is it easier to understand the problem now, Grant? |
| 2 |
|
| 3 |
Much! Thank you, Spider, I really appreciate it. |
| 4 |
|
| 5 |
On a related note, that's not the only way that our handling of binary |
| 6 |
tbz2 packages is broken. Many of our ebuilds check to see exactly which |
| 7 |
version of a dependency is installed, and that invariably leads to |
| 8 |
binary packages being broken. For example, most python packages install |
| 9 |
stuff into /usr/lib/pythonX.Y/site-packages, with the ebuild detecting |
| 10 |
what X and Y should be. The binary, however, uses whichever values of X |
| 11 |
and Y were detected when the package was built, which may well be |
| 12 |
different than the values on the target machine. Of course, this |
| 13 |
problem is far wider than just python packages. Every ebuild that uses |
| 14 |
the has_version or a related function is probably broken in this sense. |
| 15 |
|
| 16 |
My guess is that the problem I just raised could be solved by adding a |
| 17 |
portage function that runs at install-time and can either relocate files |
| 18 |
or just cause the emerge to fail with a warning, whereas the general |
| 19 |
linking issue is going to require a great deal more thought. |
| 20 |
|
| 21 |
Best, |
| 22 |
g2boojum |
Archives