[gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

[gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 1500 bytes --]

Does this look okay to you, guys? The date is preliminary and dependent
on how quickly we can get nvidia-drivers migrated to the new approach,
hopefully we can get this to happen sooner.

* * *

Title: Manual steps required during upgrade to an eselect-free OpenCL set-up
Author: Marek Szuba <marecki@gentoo.org>
Posted: 2020-05-01
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-eselect/eselect-opencl

We are now in the process of migrating OpenCL in Gentoo to having all
implementations operate through an ICD loader (dev-libs/ocl-icd or
dev-libs/opencl-icd-loader) installed directly into /usr instead of
using eselect-opencl to switch between implementations. eselect-free
versions
of loader packages have just been released to the public.

Unfortunately although the upgrade to those versions will automatically
uninstall app-eselect/eselect-opencl, it will not remove the symbolic
links to
libOpenCL.so created by this tool in library directories because those links
are not owned by the package in question. If your system is configured for
full collision protection (FEATURES=collision-protect), it will be necessary
to manually remove those links

    rm -i /usr/lib{,64}/libOpenCL.so*

before running the upgrade.

Systems whose collision protection either allows overwriting orphaned files
(FEATURES='-collision-protect protect-owned') or which do not use collision
protection at all (not recommended) should be unaffected.



-- 
MS


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

[Brian Evans]

[-- Attachment #1.1: Type: text/plain, Size: 1753 bytes --]

On 4/11/20 9:37 AM, Marek Szuba wrote:
> Does this look okay to you, guys? The date is preliminary and dependent
> on how quickly we can get nvidia-drivers migrated to the new approach,
> hopefully we can get this to happen sooner.
> 
> * * *
> 
> Title: Manual steps required during upgrade to an eselect-free OpenCL set-up
> Author: Marek Szuba <marecki@gentoo.org>
> Posted: 2020-05-01
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: app-eselect/eselect-opencl
> 
> We are now in the process of migrating OpenCL in Gentoo to having all
> implementations operate through an ICD loader (dev-libs/ocl-icd or
> dev-libs/opencl-icd-loader) installed directly into /usr instead of
> using eselect-opencl to switch between implementations. eselect-free
> versions
> of loader packages have just been released to the public.
> 
> Unfortunately although the upgrade to those versions will automatically
> uninstall app-eselect/eselect-opencl, it will not remove the symbolic
> links to
> libOpenCL.so created by this tool in library directories because those links
> are not owned by the package in question. If your system is configured for
> full collision protection (FEATURES=collision-protect), it will be necessary
> to manually remove those links
> 
>     rm -i /usr/lib{,64}/libOpenCL.so*
> 
> before running the upgrade.
> 
> Systems whose collision protection either allows overwriting orphaned files
> (FEATURES='-collision-protect protect-owned') or which do not use collision
> protection at all (not recommended) should be unaffected.
> 
> 
> 

I would mention that FEATURES='-collision-protect protect-owned' is the
default so most people won't have any action to take at all.

Brian


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 981 bytes --]

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

[Ulrich Mueller]

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

>>>>> On Sat, 11 Apr 2020, Marek Szuba wrote:

> Title: Manual steps required during upgrade to an eselect-free OpenCL set-up

Title is too long.

> Author: Marek Szuba <marecki@gentoo.org>
> Posted: 2020-05-01
> Revision: 1
> News-Item-Format: 2.0
> Display-If-Installed: app-eselect/eselect-opencl

> We are now in the process of migrating OpenCL in Gentoo to having all

Maybe avoid first person?

> implementations operate through an ICD loader (dev-libs/ocl-icd or
> dev-libs/opencl-icd-loader) installed directly into /usr instead of
> using eselect-opencl to switch between implementations. eselect-free
> versions

"eselect-free versions" is a strange term. Also, why a line break after
"versions"?

> of loader packages have just been released to the public.

> Unfortunately although the upgrade to those versions will automatically
> uninstall app-eselect/eselect-opencl, it will not remove the symbolic
> links to

Another funny line break.

> libOpenCL.so created by this tool in library directories because those links
> are not owned by the package in question. If your system is configured for
> full collision protection (FEATURES=collision-protect), it will be necessary
> to manually remove those links

>     rm -i /usr/lib{,64}/libOpenCL.so*

> before running the upgrade.

Can't this be done automatically, e.g., in pkg_preinst of the replacing
package?

> Systems whose collision protection either allows overwriting orphaned files
> (FEATURES='-collision-protect protect-owned') or which do not use collision
> protection at all (not recommended) should be unaffected.

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

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 1895 bytes --]

On 2020-04-11 14:54, Brian Evans wrote:

> I would mention that FEATURES='-collision-protect protect-owned' is 
> the default so most people won't have any action to take at all.

I've been wondering what the default is these days. Good point, in fact
I'll swap the case around so that the flow of the news item is "with
default configuration nothing will happen, if however you have strict
collision check do this".



On 2020-04-11 17:04, Ulrich Mueller wrote:

>> Title: Manual steps required during upgrade to an eselect-free 
>> OpenCL set-up
> 
> Title is too long.

OK, I'll shorten it.

>> We are now in the process of migrating OpenCL in Gentoo to having 
>> all
> 
> Maybe avoid first person?

Can do.

> "eselect-free versions" is a strange term.

How about simply "updated versions"?

> Also, why a line break after "versions"?

It's just because Thunderbird breaks lines at fewer characters than Vim
in text-file mode. It isn't present in the actual news item.

> Another funny line break.

Again, Thunderbird's fault.

>> libOpenCL.so created by this tool in library directories because 
>> those links are not owned by the package in question. If your 
>> system is configured for full collision protection 
>> (FEATURES=collision-protect), it will be necessary to manually 
>> remove those links
> 
>> rm -i /usr/lib{,64}/libOpenCL.so*
> 
>> before running the upgrade.
> 
> Can't this be done automatically, e.g., in pkg_preinst of the 
> replacing package?

I have tried doing this in pkg_preinst but alas, I have found out
collision checks are performed before that function is invoked. I have
also tried setting COLLISION_IGNORE in the replacing package but it
seems that variable only works in make.conf and make.defaults - in which
case it's simpler to simply tell the users to delete those symlinks.

-- 
MS


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] News item: manual steps required to transition from eselect-opencl to direct icd-loader use

[Ulrich Mueller]

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

>>>>> On Sat, 11 Apr 2020, Marek Szuba wrote:

> I have tried doing this in pkg_preinst but alas, I have found out
> collision checks are performed before that function is invoked. I have
> also tried setting COLLISION_IGNORE in the replacing package but it
> seems that variable only works in make.conf and make.defaults - in which
> case it's simpler to simply tell the users to delete those symlinks.

A possible (but somewhat hackish) approach would be to move the files to
a different name in src_install, and move them back to their original
name in pkg_preinst.

Ulrich

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

[gentoo-dev] News item v2: potential file collisions during OpenCL upgrade

[Marek Szuba]

[-- Attachment #1.1: Type: text/plain, Size: 2143 bytes --]

All the comments made so far have been considered. Regarding the
possibility of automating the process, I think I would rather not
bother... It feels hacky indeed, it would likely have to persist in
loader ebuilds until eselect-opencl has been removed, and it would
either require an eclass or have to be implemented independently in each
of the loader packages (not that I expect to have more than two any time
soon - but still, that's one copy of the same hack too many) - and all
of this to address a configuration that isn't even the Gentoo default.
Besides, letting the users know that something's changing in how we
handle OpenCL will IMHO not hurt even if they in the end do not have to
change anything by hand.

* * *

Title: Potential file collisions during OpenCL upgrade
Author: Marek Szuba <marecki@gentoo.org>
Posted: 2020-05-01
Revision: 1
News-Item-Format: 2.0
Display-If-Installed: app-eselect/eselect-opencl

OpenCL support in Gentoo is now being migrated to having all
implementations operate through an ICD loader (dev-libs/ocl-icd or
dev-libs/opencl-icd-loader) installed directly into /usr rather than
using eselect-opencl to switch between implementations, with updated
loader ebuilds having just been released to the public. Unfortunately
although the upgrade process will automatically uninstall
app-eselect/eselect-opencl, it will not remove the symbolic links to
libOpenCL.so created by this tool in library directories because those
links are not owned by the package in question.

For everyone using the default Gentoo configuration of collision
protection (FEATURES='-collision-protect protect-owned'), this should
cause no trouble because this configuration allows the overwriting of
orphaned files. Obviously, systems with collision protection completely
disabled (not recommended but technically possible) will not be affected
either. However, if your system is configured for full collision
protection (FEATURES=collision-protect), it will be necessary to
manually remove those links

    rm -i /usr/lib{,64}/libOpenCL.so*

before running the upgrade.


-- 
MS


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]