unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, Feb 15, 2012 at 11:11 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
> On Wed, Feb 15 2012, Mark Knecht wrote:
>
>> On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman
>> <paul.hartman+gentoo@gmail.com> wrote:
>>> On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>>>> Nvidia-drivers fails with package collisions
>>>>
>>>> ** Detected file collision(s):
>>>> **
>>>> ** * * */usr/lib32/libnvidia-compiler.so
>>>> ** * * */usr/lib32/libcuda.so
>>>> ** * * */usr/lib32/libcuda.so.1
>>>> ** * * */usr/lib64/libnvidia-compiler.so
>>>> ** * * */usr/lib64/libcuda.so
>>>> ** * * */usr/lib64/libcuda.so.1
>>>>
>>>> But the owner of all these (via a symlink) is the currently installed
>>>> version of nvidia-drivers. *For example
>>>>
>>>> * *ajglap gottlieb # equery b /usr/lib32/libcuda.so.1
>>>> * * * Searching for /usr/lib32/libcuda.so.1 ...
>>>> * *x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10)
>>>>
>>>> * *ajglap gottlieb # ls -l !$
>>>> * *ls -l /usr/lib32/libcuda.so.1
>>>> * *lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 -> OpenCL/vendors/nvidia/libcuda.so.290.10
>>>>
>>>> So I don't really see the collision. *Is the correct procedure
>>>>
>>>> 1. *Copy the 12 files (both ends of the 6 links) someplace else
>>>> 2. *Get out of X
>>>> 3. *Try the emerge again
>>>>
>>>> thanks,
>>>> allan
>>>
>>> Are the collisions with owned files, or just files that it doesn't
>>> know about? i use protect-owned so it will overwrite any unknown
>>> files, but abort on files owned by another known installed package. If
>>> portage does not report them as owned by another package I think it's
>>> usually safe to override (unless you have been installing things
>>> outside of portage).
>>>
>>
>> It may be related to all the OpenCL stuff that was just included in
>> this last set of nvidia-driver packages. Possibly the ebuild hasn't
>> handled the new stuff correctly?
>>
>> - Mark
>
> Perhaps. *All the files are links to files with OpenCL in the path.
>
> But I am still unsure what to do.
> I mentioned a three step procedure above.
> Perhaps best is to do nothing and hope -r2 will come along and
> install cleanly.
> Toward that end should I file a bug at bugs.gentoo.org?
>
> allan
>

I'm emerging the package here to investigate whether it's a global
issue or maybe just one you are seeing. I'll get back to you on that.

I think if it was me (and it may be in 10 minutes...) then I'd drop
into the console, emerge -C nvidia-drivers, probably run
revdep-rebuild or something to look for files that aren't owned,
remove them by hand, and then emerge nvidia-drivers back in.

- Mark

unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, Feb 15, 2012 at 11:43 AM, Mark Knecht <markknecht@gmail.com> wrote:
> On Wed, Feb 15, 2012 at 11:11 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>> On Wed, Feb 15 2012, Mark Knecht wrote:
>>
>>> On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman
>>> <paul.hartman+gentoo@gmail.com> wrote:
>>>> On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>>>>> Nvidia-drivers fails with package collisions
>>>>>
>>>>> ** Detected file collision(s):
>>>>> **
>>>>> ** * * */usr/lib32/libnvidia-compiler.so
>>>>> ** * * */usr/lib32/libcuda.so
>>>>> ** * * */usr/lib32/libcuda.so.1
>>>>> ** * * */usr/lib64/libnvidia-compiler.so
>>>>> ** * * */usr/lib64/libcuda.so
>>>>> ** * * */usr/lib64/libcuda.so.1
>>>>>
>>>>> But the owner of all these (via a symlink) is the currently installed
>>>>> version of nvidia-drivers. *For example
>>>>>
>>>>> * *ajglap gottlieb # equery b /usr/lib32/libcuda.so.1
>>>>> * * * Searching for /usr/lib32/libcuda.so.1 ...
>>>>> * *x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10)
>>>>>
>>>>> * *ajglap gottlieb # ls -l !$
>>>>> * *ls -l /usr/lib32/libcuda.so.1
>>>>> * *lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 -> OpenCL/vendors/nvidia/libcuda.so.290.10
>>>>>
>>>>> So I don't really see the collision. *Is the correct procedure
>>>>>
>>>>> 1. *Copy the 12 files (both ends of the 6 links) someplace else
>>>>> 2. *Get out of X
>>>>> 3. *Try the emerge again
>>>>>
>>>>> thanks,
>>>>> allan
>>>>
>>>> Are the collisions with owned files, or just files that it doesn't
>>>> know about? i use protect-owned so it will overwrite any unknown
>>>> files, but abort on files owned by another known installed package. If
>>>> portage does not report them as owned by another package I think it's
>>>> usually safe to override (unless you have been installing things
>>>> outside of portage).
>>>>
>>>
>>> It may be related to all the OpenCL stuff that was just included in
>>> this last set of nvidia-driver packages. Possibly the ebuild hasn't
>>> handled the new stuff correctly?
>>>
>>> - Mark
>>
>> Perhaps. *All the files are links to files with OpenCL in the path.
>>
>> But I am still unsure what to do.
>> I mentioned a three step procedure above.
>> Perhaps best is to do nothing and hope -r2 will come along and
>> install cleanly.
>> Toward that end should I file a bug at bugs.gentoo.org?
>>
>> allan
>>
>
> I'm emerging the package here to investigate whether it's a global
> issue or maybe just one you are seeing. I'll get back to you on that.
>
> I think if it was me (and it may be in 10 minutes...) then I'd drop
> into the console, emerge -C nvidia-drivers, probably run
> revdep-rebuild or something to look for files that aren't owned,
> remove them by hand, and then emerge nvidia-drivers back in.
>
> - Mark

OK, here I saw the same file list but the emerge didn't fail. The
installation told me it was overwriting the files because no one
claimed to own them.

That's some sort of ebuild problem and I'd agree that a bug should be filed.

HTH,
Mark

unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, Feb 15, 2012 at 2:04 PM, Mark Knecht <markknecht@gmail.com> wrote:
> On Wed, Feb 15, 2012 at 11:43 AM, Mark Knecht <markknecht@gmail.com> wrote:
>> On Wed, Feb 15, 2012 at 11:11 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>>> On Wed, Feb 15 2012, Mark Knecht wrote:
>>>
>>>> On Wed, Feb 15, 2012 at 8:12 AM, Paul Hartman
>>>> <paul.hartman+gentoo@gmail.com> wrote:
>>>>> On Wed, Feb 15, 2012 at 10:00 AM, Allan Gottlieb <gottlieb@nyu.edu> wrote:
>>>>>> Nvidia-drivers fails with package collisions
>>>>>>
>>>>>> ** Detected file collision(s):
>>>>>> **
>>>>>> ** * * */usr/lib32/libnvidia-compiler.so
>>>>>> ** * * */usr/lib32/libcuda.so
>>>>>> ** * * */usr/lib32/libcuda.so.1
>>>>>> ** * * */usr/lib64/libnvidia-compiler.so
>>>>>> ** * * */usr/lib64/libcuda.so
>>>>>> ** * * */usr/lib64/libcuda.so.1
>>>>>>
>>>>>> But the owner of all these (via a symlink) is the currently installed
>>>>>> version of nvidia-drivers. *For example
>>>>>>
>>>>>> * *ajglap gottlieb # equery b /usr/lib32/libcuda.so.1
>>>>>> * * * Searching for /usr/lib32/libcuda.so.1 ...
>>>>>> * *x11-drivers/nvidia-drivers-290.10-r1 (/usr/lib32/OpenCL/vendors/nvidia/libcuda.so.290.10)
>>>>>>
>>>>>> * *ajglap gottlieb # ls -l !$
>>>>>> * *ls -l /usr/lib32/libcuda.so.1
>>>>>> * *lrwxrwxrwx 1 root root 39 Feb 13 19:29 /usr/lib32/libcuda.so.1 -> OpenCL/vendors/nvidia/libcuda.so.290.10
>>>>>>
>>>>>> So I don't really see the collision. *Is the correct procedure
>>>>>>
>>>>>> 1. *Copy the 12 files (both ends of the 6 links) someplace else
>>>>>> 2. *Get out of X
>>>>>> 3. *Try the emerge again
>>>>>>
>>>>>> thanks,
>>>>>> allan
>>>>>
>>>>> Are the collisions with owned files, or just files that it doesn't
>>>>> know about? i use protect-owned so it will overwrite any unknown
>>>>> files, but abort on files owned by another known installed package. If
>>>>> portage does not report them as owned by another package I think it's
>>>>> usually safe to override (unless you have been installing things
>>>>> outside of portage).
>>>>>
>>>>
>>>> It may be related to all the OpenCL stuff that was just included in
>>>> this last set of nvidia-driver packages. Possibly the ebuild hasn't
>>>> handled the new stuff correctly?
>>>>
>>>> - Mark
>>>
>>> Perhaps. *All the files are links to files with OpenCL in the path.
>>>
>>> But I am still unsure what to do.
>>> I mentioned a three step procedure above.
>>> Perhaps best is to do nothing and hope -r2 will come along and
>>> install cleanly.
>>> Toward that end should I file a bug at bugs.gentoo.org?
>>>
>>> allan
>>>
>>
>> I'm emerging the package here to investigate whether it's a global
>> issue or maybe just one you are seeing. I'll get back to you on that.
>>
>> I think if it was me (and it may be in 10 minutes...) then I'd drop
>> into the console, emerge -C nvidia-drivers, probably run
>> revdep-rebuild or something to look for files that aren't owned,
>> remove them by hand, and then emerge nvidia-drivers back in.
>>
>> - Mark
>
> OK, here I saw the same file list but the emerge didn't fail. The
> installation told me it was overwriting the files because no one
> claimed to own them.
>
> That's some sort of ebuild problem and I'd agree that a bug should be filed.

That behavior can be controlled by your FEATURES settings
(collision-protect or protect-owned) and optionally modified further
in make.conf by COLLISION_IGNORE.

unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, Feb 15, 2012 at 12:49 PM, Paul Hartman
<paul.hartman+gentoo@gmail.com> wrote:
<SNIP>
>>
>> OK, here I saw the same file list but the emerge didn't fail. The
>> installation told me it was overwriting the files because no one
>> claimed to own them.
>>
>> That's some sort of ebuild problem and I'd agree that a bug should be filed.
>
> That behavior can be controlled by your FEATURES settings
> (collision-protect or protect-owned) and optionally modified further
> in make.conf by COLLISION_IGNORE.
>

Good to know. I guess the default setting must be to overwrite as I've
not made any of those setting changes.

- Mark

unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, 15 Feb 2012 13:00:57 -0800, Mark Knecht wrote:

> > That behavior can be controlled by your FEATURES settings
> > (collision-protect or protect-owned) and optionally modified further
> > in make.conf by COLLISION_IGNORE.

> Good to know. I guess the default setting must be to overwrite as I've
> not made any of those setting changes.

emerge --info will show you the settings in use.


--
Neil Bothwick

Top Oxymorons Number 48: freewill offering

unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, Feb 15, 2012 at 2:18 PM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Wed, 15 Feb 2012 13:00:57 -0800, Mark Knecht wrote:
>
>> > That behavior can be controlled by your FEATURES settings
>> > (collision-protect or protect-owned) and optionally modified further
>> > in make.conf by COLLISION_IGNORE.
>
>> Good to know. I guess the default setting must be to overwrite as I've
>> not made any of those setting changes.
>
> emerge --info will show you the settings in use.
>
>
> --
> Neil Bothwick

Of course, but if you don't know about collision-protect, for
instance, then how would one even know to put it there?

man make.conf does show the collision-protect option, along with some
others that look cool. I haven't read that man page in literally
years, if not close to a decade!

Cheers,
Mark

FEATURES="assume-digests binpkg-logs distlocks ebuild-locks fixlafiles
news parallel-fetch preserve-libs protect-owned sandbox sfperms strict
unknown-features-warn unmerge-logs unmerge-orphans userfetch"

unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, 15 Feb 2012 14:44:18 -0800, Mark Knecht wrote:

> >> Good to know. I guess the default setting must be to overwrite as
> >> I've not made any of those setting changes.
> >
> > emerge --info will show you the settings in use.

> Of course, but if you don't know about collision-protect, for
> instance, then how would one even know to put it there?

emerge --info shows the defaults and settings from your profile, not just
what you put in make.conf. I have nothing relating to collision
protection in make.conf but emerge --info shows protect-owned in FEATURES
(I think the default used to be collision-protect).


--
Neil Bothwick

This message has been cruelly tested on sweet little furry animals.

unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, Feb 15 2012, Neil Bothwick wrote:

> On Wed, 15 Feb 2012 14:44:18 -0800, Mark Knecht wrote:
>
>> >> Good to know. I guess the default setting must be to overwrite as
>> >> I've not made any of those setting changes.
>> >
>> > emerge --info will show you the settings in use.
>
>> Of course, but if you don't know about collision-protect, for
>> instance, then how would one even know to put it there?
>
> emerge --info shows the defaults and settings from your profile, not just
> what you put in make.conf. I have nothing relating to collision
> protection in make.conf but emerge --info shows protect-owned in FEATURES
> (I think the default used to be collision-protect).

That's it! I had collision-protect in make.conf. I just now removed it
and indeed emerge --info shows protect-owned. I have an emerge of
libreoffice running now. But hope tomorrow to be able to retry the
nvidia-drivers emerge and see if it goes through.

thanks,
allan

unclear package collisions in nvidia-drivers-295.20-r1
 

On Wed, 15 Feb 2012 21:31:02 -0500, Allan Gottlieb wrote:

> That's it! I had collision-protect in make.conf. I just now removed it
> and indeed emerge --info shows protect-owned. I have an emerge of
> libreoffice running now. But hope tomorrow to be able to retry the
> nvidia-drivers emerge and see if it goes through.

There's no reason why you can't do it while the LO emerge is still
running.


--
Neil Bothwick

WORM: (n.) acronym for Write Once, Read Mangled. Used to describe a
normally-functioning computer disk of the very latest design.

unclear package collisions in nvidia-drivers-295.20-r1
 

On Thu, Feb 16 2012, Neil Bothwick wrote:

> On Wed, 15 Feb 2012 21:31:02 -0500, Allan Gottlieb wrote:
>
>> That's it! I had collision-protect in make.conf. I just now removed it
>> and indeed emerge --info shows protect-owned. I have an emerge of
>> libreoffice running now. But hope tomorrow to be able to retry the
>> nvidia-drivers emerge and see if it goes through.
>
> There's no reason why you can't do it while the LO emerge is still
> running.

First, let me report success (I ran the emerge of nvidia-drivers after
LO finished and it worked fine) and thanks.

I didn't realize that I could run emerges together.
The emerge of LO was the penultimate merge coming from an
emerge update world
(the last was LO-l10n)
While this LO merge was in progress could I have safely started another
emerge update world
?

I am guessing the point is that, since the running emerge was
essentially just LO, it was safe to run the nvidia-drivers emerge since
there are no shared dependencies. Is emerge by some chance clever
enough that you can always start an update world, while one is running?

thanks again,
allan