| 1 |
begin quote |
| 2 |
On Thu, 05 Feb 2004 07:59:37 -0500 |
| 3 |
Grant Goodyear <g2boojum@g.o> wrote: |
| 4 |
|
| 5 |
> > Is it easier to understand the problem now, Grant? |
| 6 |
> |
| 7 |
> Much! Thank you, Spider, I really appreciate it. |
| 8 |
> |
| 9 |
> On a related note, that's not the only way that our handling of binary |
| 10 |
> |
| 11 |
> tbz2 packages is broken. Many of our ebuilds check to see exactly |
| 12 |
> which |
| 13 |
> version of a dependency is installed, and that invariably leads to |
| 14 |
> binary packages being broken. For example, most python packages |
| 15 |
> install stuff into /usr/lib/pythonX.Y/site-packages, with the ebuild |
| 16 |
> detecting what X and Y should be. The binary, however, uses whichever |
| 17 |
> values of X and Y were detected when the package was built, which may |
| 18 |
> well be different than the values on the target machine. Of course, |
| 19 |
> this problem is far wider than just python packages. Every ebuild |
| 20 |
> that uses the has_version or a related function is probably broken in |
| 21 |
> this sense. |
| 22 |
> |
| 23 |
> My guess is that the problem I just raised could be solved by adding a |
| 24 |
> |
| 25 |
> portage function that runs at install-time and can either relocate |
| 26 |
> files or just cause the emerge to fail with a warning, whereas the |
| 27 |
> general linking issue is going to require a great deal more thought. |
| 28 |
|
| 29 |
|
| 30 |
Very true and another headache. It somehow feels that we need a |
| 31 |
thinker on how to deal with this. Anyone here who feels exceptionally |
| 32 |
bright this afternoon? |
| 33 |
|
| 34 |
//Spider |
| 35 |
-- dead tired |
| 36 |
-- |
| 37 |
begin .signature |
| 38 |
This is a .signature virus! Please copy me into your .signature! |
| 39 |
See Microsoft KB Article Q265230 for more information. |
| 40 |
end |
Archives