| 1 |
On Wed, Feb 15, 2012 at 11:43 AM, Mark Knecht <markknecht@×××××.com> wrote: |
| 2 |
> On Wed, Feb 15, 2012 at 11:11 AM, Allan Gottlieb <gottlieb@×××.edu> wrote: |
| 3 |
>> On Wed, Feb 15 2012, Mark Knecht wrote: |
| 4 |
>> |
| 5 |
>>> On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman |
| 6 |
>>> <paul.hartman+gentoo@×××××.com> wrote: |
| 7 |
>>>> On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb <gottlieb@×××.edu> wrote: |
| 8 |
>>>>> Nvidia-drivers fails with package collisions |
| 9 |
>>>>> |
| 10 |
>>>>> * Detected file collision(s): |
| 11 |
>>>>> * |
| 12 |
>>>>> * /usr/lib32/libnvidia-compiler.so |
| 13 |
>>>>> * /usr/lib32/libcuda.so |
| 14 |
>>>>> * /usr/lib32/libcuda.so.1 |
| 15 |
>>>>> * /usr/lib64/libnvidia-compiler.so |
| 16 |
>>>>> * /usr/lib64/libcuda.so |
| 17 |
>>>>> * /usr/lib64/libcuda.so.1 |
| 18 |
>>>>> |
| 19 |
>>>>> But the owner of all these (via a symlink) is the currently installed |
| 20 |
>>>>> version of nvidia-drivers. For example |
| 21 |
>>>>> |
| 22 |
>>>>> ajglap gottlieb # equery b /usr/lib32/libcuda.so.1 |
| 23 |
>>>>> * Searching for /usr/lib32/libcuda.so.1 ... |
| 24 |
>>>>> x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10) |
| 25 |
>>>>> |
| 26 |
>>>>> ajglap gottlieb # ls -l !$ |
| 27 |
>>>>> ls -l /usr/lib32/libcuda.so.1 |
| 28 |
>>>>> lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 -> OpenCL/vendors/nvidia/libcuda.so.290.10 |
| 29 |
>>>>> |
| 30 |
>>>>> So I don't really see the collision. Is the correct procedure |
| 31 |
>>>>> |
| 32 |
>>>>> 1. Copy the 12 files (both ends of the 6 links) someplace else |
| 33 |
>>>>> 2. Get out of X |
| 34 |
>>>>> 3. Try the emerge again |
| 35 |
>>>>> |
| 36 |
>>>>> thanks, |
| 37 |
>>>>> allan |
| 38 |
>>>> |
| 39 |
>>>> Are the collisions with owned files, or just files that it doesn't |
| 40 |
>>>> know about? i use protect-owned so it will overwrite any unknown |
| 41 |
>>>> files, but abort on files owned by another known installed package. If |
| 42 |
>>>> portage does not report them as owned by another package I think it's |
| 43 |
>>>> usually safe to override (unless you have been installing things |
| 44 |
>>>> outside of portage). |
| 45 |
>>>> |
| 46 |
>>> |
| 47 |
>>> It may be related to all the OpenCL stuff that was just included in |
| 48 |
>>> this last set of nvidia-driver packages. Possibly the ebuild hasn't |
| 49 |
>>> handled the new stuff correctly? |
| 50 |
>>> |
| 51 |
>>> - Mark |
| 52 |
>> |
| 53 |
>> Perhaps. All the files are links to files with OpenCL in the path. |
| 54 |
>> |
| 55 |
>> But I am still unsure what to do. |
| 56 |
>> I mentioned a three step procedure above. |
| 57 |
>> Perhaps best is to do nothing and hope -r2 will come along and |
| 58 |
>> install cleanly. |
| 59 |
>> Toward that end should I file a bug at bugs.gentoo.org? |
| 60 |
>> |
| 61 |
>> allan |
| 62 |
>> |
| 63 |
> |
| 64 |
> I'm emerging the package here to investigate whether it's a global |
| 65 |
> issue or maybe just one you are seeing. I'll get back to you on that. |
| 66 |
> |
| 67 |
> I think if it was me (and it may be in 10 minutes...) then I'd drop |
| 68 |
> into the console, emerge -C nvidia-drivers, probably run |
| 69 |
> revdep-rebuild or something to look for files that aren't owned, |
| 70 |
> remove them by hand, and then emerge nvidia-drivers back in. |
| 71 |
> |
| 72 |
> - Mark |
| 73 |
|
| 74 |
OK, here I saw the same file list but the emerge didn't fail. The |
| 75 |
installation told me it was overwriting the files because no one |
| 76 |
claimed to own them. |
| 77 |
|
| 78 |
That's some sort of ebuild problem and I'd agree that a bug should be filed. |
| 79 |
|
| 80 |
HTH, |
| 81 |
Mark |
Archives