Summary: | x11-themes/gentoo-xcursors-0.3.2-r2 creates incorrect symlinks | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Peter Penkala <pjp> |
Component: | Current packages | Assignee: | tastytea <gentoo> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | 1i5t5.duncan, proxy-maint, x11 |
Priority: | Normal | Keywords: | PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=848606 https://bugs.gentoo.org/show_bug.cgi?id=834600 https://github.com/gentoo/gentoo/pull/26651 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Peter Penkala
2022-07-28 23:24:24 UTC
The directories under /usr/share/cursors/xorg-x11/ should contain a directory named “cursors”, according to x11-themes/xcursor-themes and x11-themes/comix-xcursors. So the symlink seems to be correct, unless the other packages are wrong too. It would seem that Adwaita points to the wrong location? I could reproduce the blocked symlink installation problem and will investigate. Hoping to be of help here since I feel kind of responsible given my earlier bug... I believe what's happening is due to upgrading in-place, while as I reported testing in https://bugs.gentoo.org/848606#c2 , I did an unmerge of the old version first, thereby testing a clean install, not an upgrade. In hindsight I should have tested both a clean install, and after unmerging that and remerging the earlier package, an upgrade. I /thought/ that fix was easier than it should be. Now I know why. Anyway... (In reply to Peter Penkala from comment #0) > ERROR: preinst > > Installation of a symlink is blocked by a directory: > '/usr/share/cursors/xorg-x11/gentoo' > This symlink will be merged with a different name: > '/usr/share/cursors/xorg-x11/gentoo.backup.0000' (Listing just the first of three, one for each sub-theme.) That's going to be while the existing package dirs are still there, because in the upgrade case, the new package is installed first, with non-duplicated bits of the old one only removed afterward. (This order is to prevent missing critical functionality during the would-be gap if done in reverse, when core packages such as grep and coreutils are upgraded. Unfortunately it complicates dir-to-symlink upgrade cases such as this one.) > Actual Results: > The other bug references Adwaita as an example, so I'm including how it > exists on my system (other files excluded): > $ ls -l /usr/share/cursors/xorg-x11/ > total 28 > lrwxrwxrwx 1 root root 43 Jun 8 17:42 Adwaita -> > ../../../../usr/share/icons/Adwaita/cursors Relative path backs up to root (/), path from there thru icons/theme to its cursors subdir. > drwxr-xr-x 2 root root 4096 Jul 27 16:39 gentoo > lrwxrwxrwx 1 root root 18 Jul 27 16:38 gentoo.backup.0000 -> > ../../icons/gentoo Relative path backs up to /usr/share, path from there to icons/theme itself (not its cursors subdir). AFAIK they're both relative and backing up the extra two elements shouldn't be an issue. (This was the bit I originally focused on but it's gotta be a rabbit trail to nowhere.) The trailing (cursors/theme/)cursors subdir bit (which it seems the focus was on but for me), *could* be an issue, but I don't believe it's the issue here. (The issue would be one of whether a search into the gentoo-specific /usr/share/cursors/ recurses from theme into theme/cursors subdirs or not. With examples of both evidently it did, but AFAIK that's irrelevant from our dir-blocking-symlink-error perspective.) And just to eliminate another possible source of confusion that at least I kept trying to rabbit-trail into, keep in mind that we're linking from the gentoo-specific /usr/share/cursors location to the standard /usr/share/icons location, two different subdirs, so it's not a self-referencial symlink looping issue either. > $ ls -l /usr/share/cursors/xorg-x11/gentoo-blue.backup.0000/ > total 4 > drwxr-xr-x 2 root root 4096 Jul 27 16:39 cursors > > Expected Results: > I would expect the path to look either like the existing Adwaita link, or > perhaps: > gentoo-blue -> ../../icons/gentoo-blue/cursors Again, I /think/ that's a rabbit-trail (tho different from the ones I kept trying to go down, this symlink-tracing stuff can be maddening, so rabbit-trailing in one way or another is entirely understandable!). I believe the problem here, as I said, is with the upgrade path, as opposed to a clean-install path (which from my testing works so an unmerge/clean-merge should be a practical workaround until the bug is fixed). Assuming that, then, a hacky solution might involve testing for the upgrade case and force-removing the existing dirs so they don't interfere with the upgrade, but there's likely a less hacky "proper" way to do it as well. Have any other theme packages already dealt with this, providing a pattern we can follow? Related to bug 834600, I think. (In reply to tastytea from comment #1) > The directories under /usr/share/cursors/xorg-x11/ should contain a directory > named “cursors”, according to x11-themes/xcursor-themes and > x11-themes/comix-xcursors. So the symlink seems to be correct, unless the > other > packages are wrong too. It would seem that Adwaita points to the wrong > location? > > I could reproduce the blocked symlink installation problem and will > investigate. I very well may not understand where the symlinks were supposed to point. After reviewing your response, the symlink does work, but then the block is confusing. $ ls -1d ../../icons/gentoo/cursors ../../icons/gentoo/cursors If I understand your reference, your saying there should be a cursors under each "theme" (?) directory, as in /usr/share/cursors/xorg-x11/<directory>/cursors I can confirm that exists: $ find /usr/share/cursors/xorg-x11/ -type d -name cursors /usr/share/cursors/xorg-x11/gentoo/cursors /usr/share/cursors/xorg-x11/gentoo-blue/cursors /usr/share/cursors/xorg-x11/redglass/cursors /usr/share/cursors/xorg-x11/gentoo-silver/cursors /usr/share/cursors/xorg-x11/handhelds/cursors /usr/share/cursors/xorg-x11/whiteglass/cursors /usr/share/cursors/xorg-x11/DMZ-White/cursors Adwaita does not because it is a symlink. It does however point to the "icons" theme cusor directory. # ls -ld /usr/share/cursors/xorg-x11/Adwaita lrwxrwxrwx 1 root root 43 Jun 8 17:42 /usr/share/cursors/xorg-x11/Adwaita -> ../../../../usr/share/icons/Adwaita/cursors Or, if you meant /usr/share/icons/<directory>/cursors those too exist: $ find /usr/share/icons/ -type d -name cursors /usr/share/icons/gentoo/cursors /usr/share/icons/gentoo-blue/cursors /usr/share/icons/gentoo-silver/cursors /usr/share/icons/Adwaita/cursors Let me know if I can provide anything else, thanks! (In reply to Duncan from comment #2) > Have any other theme packages already dealt with this, providing a pattern > we can follow? First place I looked... the adwaita-icon-theme-42.0_p2 ebuild (it's not in the older 3.32.0): pkg_preinst() { # Needed until bug #834600 is solved if [[ -d "${EROOT}"/usr/share/cursors/xorg-x11/Adwaita ]] ; then rm -r "${EROOT}"/usr/share/cursors/xorg-x11/Adwaita || die fi } Bug #834600 is only from March of this year (2022) and has to do with portage not (yet) being able to handle replacing dirs with symlinks (or the reverse, symlinks with dirs), even when owned by a previous version of the same package in the upgrade case (where overwrite should be reasonably safe). And its comment 2 https://bugs.gentoo.org/834600#c2 mentions exactly the hacky solution above, removal in pkg_preinst. Tho a slightly safer version would test that it's an upgrade/downgrade case (${REPLACING_VERSIONS}) before doing the removal. Maybe something like (just in case, signed-off-by: John Duncan): pkg_preinst() { # Needed until bug #834600 is solved [[ ${REPLACING_VERSIONS} ]] && { GENTOOCURSORS="${EROOT}/usr/share/cursors/xorg-x11" if [[ -d "${GENTOOCURSORS}/gentoo" ]] ; then rm -r "${GENTOOCURSORS}/gentoo" || die fi if [[ -d "${GENTOOCURSORS}/gentoo-blue" ]] ; then rm -r "${GENTOOCURSORS}/gentoo-blue" || die fi if [[ -d "${GENTOOCURSORS}/gentoo-silver" ]] ; then rm -r "${GENTOOCURSORS}/gentoo-silver" || die fi fi } (In reply to Duncan from comment #5) > pkg_preinst() { > # Needed until bug #834600 is solved > [[ ${REPLACING_VERSIONS} ]] && { > GENTOOCURSORS="${EROOT}/usr/share/cursors/xorg-x11" > if [[ -d "${GENTOOCURSORS}/gentoo" ]] ; then > rm -r "${GENTOOCURSORS}/gentoo" || die > fi > if [[ -d "${GENTOOCURSORS}/gentoo-blue" ]] ; then > rm -r "${GENTOOCURSORS}/gentoo-blue" || die > fi > if [[ -d "${GENTOOCURSORS}/gentoo-silver" ]] ; then > rm -r "${GENTOOCURSORS}/gentoo-silver" || die > fi > fi > } Oops. That last fi should be } (In reply to Peter Penkala from comment #4) > If I understand your reference, your saying there should be a cursors under > each "theme" (?) directory, as in > /usr/share/cursors/xorg-x11/<directory>/cursors Yes, every cursor theme but Adwaita seems to use this layout. > Adwaita does not because it is a symlink. It does however point to the > "icons" theme cusor directory. > # ls -ld /usr/share/cursors/xorg-x11/Adwaita > lrwxrwxrwx 1 root root 43 Jun 8 17:42 /usr/share/cursors/xorg-x11/Adwaita > -> ../../../../usr/share/icons/Adwaita/cursors From <https://www.x.org/releases/X11R7.7/doc/man/man3/Xcursor.3.xhtml>: > Xcursor (mostly) follows the freedesktop.org spec for theming icons. The > default search path it uses is ~/.icons, /usr/share/icons, /usr/share/pixmaps. > Within each of these directories, it searches for a directory using the theme > name. Within the theme directory, it looks for cursor files in the ’cursors’ > subdirectory. It uses the first cursor file found along the path. Since in Gentoo the default search path is /usr/share/cursors/xorg-x11 (`pkg-config --variable=icondir xcursor`), /usr/share/cursors/xorg-x11/{Adwaita,gentoo}/cursors should exist IMO. On the other hand, “It uses the first cursor file found along the path.” could be read as: It searches in the theme directory for cursor files and, if nothing was found, tries the cursor subdirectory. So either the Adwaita path is wrong or both Adwaita's and gentoo-xcursors's path is right. Having the cursors in <xcursor-path>/<theme>/cursors seems to be the safest. > Keywords: PullRequest
> See Also: https://github.com/gentoo/gentoo/pull/26651
The failed-upgrade/backup symlinks detail is nice. =:^)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=477015c0b557b557c8cd527b93fd5ba8d6b42000 commit 477015c0b557b557c8cd527b93fd5ba8d6b42000 Author: Ronny (tastytea) Gutbrod <gentoo@tastytea.de> AuthorDate: 2022-07-29 11:21:06 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-07-30 23:22:29 +0000 x11-themes/gentoo-xcursors: fix blocked symlink installation A directory was replaced by a symlink but that does not work due to bug #834600. Straight to stable since the broken ebuild landed in stable and the package isn't compiling anything. Closes: https://bugs.gentoo.org/861785 Co-developed-by: John Duncan Signed-off-by: Ronny (tastytea) Gutbrod <gentoo@tastytea.de> Signed-off-by: Sam James <sam@gentoo.org> .../gentoo-xcursors-0.3.2-r3.ebuild | 51 ++++++++++++++++++++++ 1 file changed, 51 insertions(+) This is only informational feedback. The upgrade produced these results with no errors: $ ls -l /usr/share/cursors/xorg-x11/ |grep gentoo lrwxrwxrwx 1 root root 18 Jul 31 20:50 gentoo -> ../../icons/gentoo lrwxrwxrwx 1 root root 18 Jul 28 21:06 gentoo.backup.0000 -> ../../icons/gentoo lrwxrwxrwx 1 root root 23 Jul 31 20:50 gentoo-blue -> ../../icons/gentoo-blue lrwxrwxrwx 1 root root 23 Jul 28 21:06 gentoo-blue.backup.0000 -> ../../icons/gentoo-blue lrwxrwxrwx 1 root root 25 Jul 31 20:50 gentoo-silver -> ../../icons/gentoo-silver lrwxrwxrwx 1 root root 25 Jul 28 21:06 gentoo-silver.backup.0000 -> ../../icons/gentoo-silver qfile reports no ownership of the "backup" directories. After uninstalling, they remain as dead links. Cleaning up the dead links and reinstalling the new package produces the following, which looks more like what I expected from the upgrade process: $ ls -l /usr/share/cursors/xorg-x11/ |grep gentoo lrwxrwxrwx 1 root root 18 Jul 31 21:03 gentoo -> ../../icons/gentoo lrwxrwxrwx 1 root root 23 Jul 31 21:03 gentoo-blue -> ../../icons/gentoo-blue lrwxrwxrwx 1 root root 25 Jul 31 21:03 gentoo-silver -> ../../icons/gentoo-silver I presume the backup links are intentional, but I preferred the clean install. Thanks (In reply to Peter Penkala from comment #10) > […] > > I presume the backup links are intentional, but I preferred the clean > install. Yes, i decided to not touch the previously generated backup directories. Because the package does not own them, it should not touch them, in my opinion. It will output an informational message if it detects them though. <https://cgit.gentoo.org/repo/gentoo.git/tree/x11-themes/gentoo-xcursors/gentoo-xcursors-0.3.2-r3.ebuild?id=477015c#n41> |