[gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Allan Gottlieb]

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

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Paul Hartman]

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).

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Mark Knecht]

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

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Allan Gottlieb]

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

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Mark Knecht]

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

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Mark Knecht]

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

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Paul Hartman]

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.

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Mark Knecht]

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

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 474 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Mark Knecht]

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"

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 732 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Allan Gottlieb]

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

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Allan Gottlieb]

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


    

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Hinnerk van Bruinehsen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 16.02.2012 14:09, Allan Gottlieb wrote:
> 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
> 
> 
Two "emerge update world"s I wouldn't recommend, because most likely
you would emerge some packages two times. emerge <package> while
"emerge --update world" is running is reasonably stable, at least in
my experience.
The biggest problem is slowdown and maybe out-of-memory-errors if you
emerge multiple big packages (e.g. libre office and chromium).

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJPPQL4AAoJEJwwOFaNFkYcEkkIAKPS7VgHjeFC6eG700aMOu/7
PHvgkKpsyeEZO78V65zFJePMyNBSzbskY5uXCtz2MLLHsuSkyznvJxzXNy/kycL8
6vFAHx6yKgQeudTaXkYxh9FhhVRSbnkedBqVR1x2k+1yhHTjQdsG5iDq0yBZucYi
Hij1KIPKuylhAegp6v0c37dHbB9y9dmKAIW8wYxGfU2sOj6om2ALFZgKWfS1UpQx
1oWjWW93SV68qGVEGXDAyW1DvfDAhfYXF4b6WkCfBBZGVAyRtfRbSIQCs5R6piJi
lr97+765+FFOXc/4DxtNPL4bLg40iEynJRQUJrQV2ukibAFusACfskB9MFpg4WY=
=Bw/t
-----END PGP SIGNATURE-----

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On Thu, 16 Feb 2012 08:09:38 -0500, Allan Gottlieb wrote:

> 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

No, because LO still needed to be updated, so you'd have ended up trying
to compile it twice in parallel.

> 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?

There's an easy way to test this, if we don't hear back from you I'll
assume it is not safe :)


-- 
Neil Bothwick

Windows will never cease.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] unclear package collisions in nvidia-drivers-295.20-r1

[Allan Gottlieb]

On Wed, Feb 15 2012, Paul Hartman 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 ran equery belongs   and each of those files are owned
by nvidia-drivers, the package that is being emerged.

They are of course owned by the current version -295.10-r1.
I am trying to merge the new version -295.20-r1.

thanks
allan