| 1 |
All the comments made so far have been considered. Regarding the |
| 2 |
possibility of automating the process, I think I would rather not |
| 3 |
bother... It feels hacky indeed, it would likely have to persist in |
| 4 |
loader ebuilds until eselect-opencl has been removed, and it would |
| 5 |
either require an eclass or have to be implemented independently in each |
| 6 |
of the loader packages (not that I expect to have more than two any time |
| 7 |
soon - but still, that's one copy of the same hack too many) - and all |
| 8 |
of this to address a configuration that isn't even the Gentoo default. |
| 9 |
Besides, letting the users know that something's changing in how we |
| 10 |
handle OpenCL will IMHO not hurt even if they in the end do not have to |
| 11 |
change anything by hand. |
| 12 |
|
| 13 |
* * * |
| 14 |
|
| 15 |
Title: Potential file collisions during OpenCL upgrade |
| 16 |
Author: Marek Szuba <marecki@g.o> |
| 17 |
Posted: 2020-05-01 |
| 18 |
Revision: 1 |
| 19 |
News-Item-Format: 2.0 |
| 20 |
Display-If-Installed: app-eselect/eselect-opencl |
| 21 |
|
| 22 |
OpenCL support in Gentoo is now being migrated to having all |
| 23 |
implementations operate through an ICD loader (dev-libs/ocl-icd or |
| 24 |
dev-libs/opencl-icd-loader) installed directly into /usr rather than |
| 25 |
using eselect-opencl to switch between implementations, with updated |
| 26 |
loader ebuilds having just been released to the public. Unfortunately |
| 27 |
although the upgrade process will automatically uninstall |
| 28 |
app-eselect/eselect-opencl, it will not remove the symbolic links to |
| 29 |
libOpenCL.so created by this tool in library directories because those |
| 30 |
links are not owned by the package in question. |
| 31 |
|
| 32 |
For everyone using the default Gentoo configuration of collision |
| 33 |
protection (FEATURES='-collision-protect protect-owned'), this should |
| 34 |
cause no trouble because this configuration allows the overwriting of |
| 35 |
orphaned files. Obviously, systems with collision protection completely |
| 36 |
disabled (not recommended but technically possible) will not be affected |
| 37 |
either. However, if your system is configured for full collision |
| 38 |
protection (FEATURES=collision-protect), it will be necessary to |
| 39 |
manually remove those links |
| 40 |
|
| 41 |
rm -i /usr/lib{,64}/libOpenCL.so* |
| 42 |
|
| 43 |
before running the upgrade. |
| 44 |
|
| 45 |
|
| 46 |
-- |
| 47 |
MS |
Archives