--- /usr/lib64/gimp/ --- /usr/lib64/gimp/2.0/ --- /usr/lib64/gimp/2.0/plug-ins/ * * Installation of a directory is blocked by a file: * '/usr/lib64/gimp/2.0/plug-ins/web-browser' * This file will be renamed to a different name: * '/usr/lib64/gimp/2.0/plug-ins/web-browser.backup.0000' * bak /usr/lib64/gimp/2.0/plug-ins/web-browser /usr/lib64/gimp/2.0/plug-ins/web-browser.backup >>> /usr/lib64/gimp/2.0/plug-ins/web-browser/ >>> /usr/lib64/gimp/2.0/plug-ins/web-browser/web-browser * * Installation of a directory is blocked by a file: * '/usr/lib64/gimp/2.0/plug-ins/wavelet-decompose' * This file will be renamed to a different name: * '/usr/lib64/gimp/2.0/plug-ins/wavelet-decompose.backup.0000' * bak /usr/lib64/gimp/2.0/plug-ins/wavelet-decompose /usr/lib64/gimp/2.0/plug-ins/wavelet-decompose.backup [...] Besides it being forbidden by the PMS, the awful Portage implementation leaves a lot of cruft on the filesystem which can't be cleaned up automatically.
Created attachment 545586 [details] media-gfx:gimp-2.10.6:20180831-063446.log.xz
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=62af963b40ddca8162f74b7bc0872ff442cce6a0 commit 62af963b40ddca8162f74b7bc0872ff442cce6a0 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2018-08-31 07:31:16 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2018-08-31 07:31:16 +0000 package.mask: Mask new gimp for QA violations Bug: https://bugs.gentoo.org/664938 profiles/package.mask | 6 ++++++ 1 file changed, 6 insertions(+)
I there a way to clean those files?
Manual cleanup as far as i did Uninstall the new version look for .backup.0000 in folder: /usr/lib64/gimp/2.0/plug-ins/ then manually remove them ** Careful a few other packages can have plugins in that folder ** Once cleaned up you can emerge the previous version or re-emerge the new version, since its masked now, you might as well just keep the old version until this new one has been corrected to not leave a mess around in the folder tree...
You might have dependencies stopping you from uninstalling it so you are likely going to want to do in this case emerge -aC gimp to force it out and just do your cleanup carefully and re-merge the previous version back The preserved libs you are likely to get in this case will give you a good idea on the packages that are likely to have plugins installed in the Gimp folder If you qlist the packages you can see what files they have in the gimp folders and avoid removing them when you clean up
(In reply to Marek Bartosiewicz from comment #3) > I there a way to clean those files? Ran the following to clean up: find /usr/lib64/gimp/2.0/plug-ins/ -iname '*.backup.*' -ls -delete find /usr/lib64/gimp/2.0/plug-ins/ -type d -empty -exec rmdir {} \; Then re-emerge gimp.
(In reply to Michał Górny from comment #0) > Besides it being forbidden by the PMS, the awful Portage implementation > leaves a lot of cruft on the filesystem which can't be cleaned up > automatically. I don't see why it can't be done automatically. The file name patterns are well-known and removing the empty directories is easy as I've shown in a prior comment: find /usr/lib64/gimp/2.0/plug-ins/ -iname '*.backup.*' -ls -delete find /usr/lib64/gimp/2.0/plug-ins/ -type d -empty -exec rmdir {} \; Also, the files on the system can be compared to what it's in /var/db/pkg/media-gfx/gimp-*/CONTENTS. Anything that is within the directories listed in the CONTENTS file but not on the list as obj/sym can 99% of the time be removed (unless it's under CONFIG_PROTECT).
The directories are empty, the replaced files are ELFs. I'd say that for some that's NOT only a QA bug but also a (big?) LOSS of functionality for Gimp. At least when you remove those files (gimp will scan and read 0001 and 000n files too). Oh, and source of additional ABI/API bug since those 0001 .. 000n plugins are from previous versions of Gimp
Ah, no! Plugins are inside the directories when gimp 2.10.6 is installed. Downgrade however make those directory empty _and_ the package cannot install the plugins over an existing directory. So after gimp 2.10.6 uninstall and _after_ cleaning like explained in #c7 (find ....) you should re-emerge gimp 2.10.4 or better
I can only think of dirty hacks that you won't like for a fix right now. That would be adding pkg_preinst/pkg_postinst things to multiple ebuilds. How not-okay does that sound to to you? Any recommendations for a fix from inside the ebuild?
(In reply to Sebastian Pipping from comment #10) > I can only think of dirty hacks that you won't like for a fix right now. > That would be adding pkg_preinst/pkg_postinst things to multiple ebuilds. > How not-okay does that sound to to you? > > Any recommendations for a fix from inside the ebuild? Sebastian, just inform the users how to clean the mess, maybe it's news worthy Cleaning by hand or whit a simple script isn't difficult, do it cleanly inside ebuilds is (In reply to Andrew Udvare from comment #7) > Also, the files on the system can be compared to what it's in > /var/db/pkg/media-gfx/gimp-*/CONTENTS. Anything that is within the > directories listed in the CONTENTS file but not on the list as obj/sym can > 99% of the time be removed (unless it's under CONFIG_PROTECT). There are other packages writing in that directory, i.e. gmic and gutenprint. and it's a sandbox violation to work on files outside of portage tmpdir. And you mus keep that cleaning in ebuild forever It will be messy and it's good that QA catched this soon rather than later
If upstream is really insane enough to suddenly change the plugin install layout, then the directory used to keep them should be changed as well for a clean migration.
Inside /usr/lib64/gimp/2.0/plug-ins/ there seems to be a rule that for a plug-in to be loaded by 2.10.6 subfolder and ELF file name need to match, e.g. - file-gif-load/file-gif-load is good - file-gif-load/file-gif-load.elf won't load - core-file-gif-load/core-file-gif-load seems to load fine So I'm considering to make src_install process ${D}/usr/lib64/gimp/2.0/plug-ins/ files in a way that "foo/foo" is renamed to "core-foo/core-foo" to mitigate the collision issue we have here. Any strong objections to that approach?
It seems that making this change in configure.ac: -m4_define([gimp_plugin_version], [2.0]) +m4_define([gimp_plugin_version], [2.10]) Would cause GIMP to use "/usr/lib64/gimp/2.10/plug-ins" directory instead of "/usr/lib64/gimp/2.0/plug-ins".
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #14) If this solution is used, then probably SLOT="2/2.10" should be set.
Relevant upstream commits in gimp-2-10 branch: https://gitlab.gnome.org/GNOME/gimp/commit/79961a654559e06cd853a4337bd1e97e963ec080 "plug-ins: install plug-ins in subfolder." https://gitlab.gnome.org/GNOME/gimp/commit/25f099344fbf44b0c02e9db23ce26c61c749ee54 "plug-ins: make plug-ins inside common/ to also install in subfolders." https://gitlab.gnome.org/GNOME/gimp/commit/5682a01626915ccbec7a60fcaf3df097bbc7d259 "plug-ins: fix individual install targets of common plug-ins." https://gitlab.gnome.org/GNOME/gimp/commit/035c7854902174978001e42bf700b0869cce5ce8 "Issue #788: also install all python plug-ins in their own directory." https://gitlab.gnome.org/GNOME/gimp/commit/55a7872e1be44102a66d6de07e6ea9e33d84c416 "plug-ins: include the right python source in the distribution."
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #14) > It seems that making this change in configure.ac: > -m4_define([gimp_plugin_version], [2.0]) > +m4_define([gimp_plugin_version], [2.10]) > > Would cause GIMP to use "/usr/lib64/gimp/2.10/plug-ins" directory instead of > "/usr/lib64/gimp/2.0/plug-ins". Still unsure if that's causing more good or harm. Our plug-in ebuilds (e.g. lensfun) use $(gimptool-2.0 --gimpplugindir)/plug-ins for installation. (In reply to Arfrever Frehtes Taifersar Arahesis from comment #15) > (In reply to Arfrever Frehtes Taifersar Arahesis from comment #14) > > If this solution is used, then probably SLOT="2/2.10" should be set. Given we do change plug-in paths, that seems like a good idea.
The value printed by 'gimptool-2.0 --gimpplugindir' should automatically change if idea suggested in comment 14 is implemented. And only then, changing subslot would make sense.
Looking forward to a solution, as Sabayon won't package 2.10.6 until this is fixed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=fea4860e2c82475880cf566e304f41df80c99f69 commit fea4860e2c82475880cf566e304f41df80c99f69 Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2018-09-24 19:59:36 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2018-09-24 20:38:37 +0000 media-gfx/gimp: Avoid colliding with pre-2.10.6 plug-ins Bug: https://bugs.gentoo.org/664938 Package-Manager: Portage-2.3.49, Repoman-2.3.10 media-gfx/gimp/gimp-2.10.6-r1.ebuild | 219 +++++++++++++++++++++++++++++++++++ media-gfx/gimp/gimp-9999.ebuild | 19 +++ 2 files changed, 238 insertions(+)
If the rename-approach demoed in 2.10.6-r1 works well enough, we can remove r0 and the mask and close this ticket (but no rush). I went for this approach because it fixes things where they are cause rather than everywhere else. If renaming turns out to break some plug-in, we can still do another round with a bigger gun.
> + ( > + cd "${ED%/}"/usr/$(get_libdir)/gimp/2.0/plug-ins || exit 1 Instead of subshell, 'cd' and 'exit', you could use 'pushd' + 'popd', local variables and 'die': pushd "${ED%/}"/usr/$(get_libdir)/gimp/2.0/plug-ins > /dev/null || die local ... for ... ... done popd > /dev/null || die > + mv ${plugin}/{,${prepend}}${plugin} || exit 1 > + mv {,${prepend}}${plugin} || exit 1 'mv' could be called only once per plugin, in more readable way: mv ${plugin}/${plugin} ${prepend}${plugin}/${prepend}${plugin} || die
(And if subshell and 'exit' are eliminated, then '_rename_plugins || die' can become '_rename_plugins'.)
(In reply to Arfrever Frehtes Taifersar Arahesis from comment #22) > pushd "${ED%/}"/usr/$(get_libdir)/gimp/2.0/plug-ins > /dev/null || die > local ... > for ... > ... > done > popd > /dev/null || die I'm aware of pushd and like it, no objections to that change, but it doesn't add enough value in my book for the time it takes to get that changed and tested. If anyone wants to adjust it, please make sure to adjust both copies and test it. Thanks! > > + mv ${plugin}/{,${prepend}}${plugin} || exit 1 > > + mv {,${prepend}}${plugin} || exit 1 > > 'mv' could be called only once per plugin, in more readable way: > > mv ${plugin}/${plugin} ${prepend}${plugin}/${prepend}${plugin} || die There is no folder ${prepend}${plugin} so that mv would fail. Am I missing something?
Anyway upgrade from media-gfx/gimp-2.10.4 to media-gfx/gimp-2.10.6-r1 was successful for me. The entry in package.mask is "=media-gfx/gimp-2.10.6", so it does not match media-gfx/gimp-2.10.6-r1, so users have been exposed for several days to media-gfx/gimp-2.10.6-r1... I suggest to drop media-gfx/gimp-2.10.6 ebuild and the then-obsolete entry in package.mask.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f6423b9be2f75be9dc88d76c7c22a2054725f55c commit f6423b9be2f75be9dc88d76c7c22a2054725f55c Author: Sebastian Pipping <sping@gentoo.org> AuthorDate: 2018-09-29 15:29:05 +0000 Commit: Sebastian Pipping <sping@gentoo.org> CommitDate: 2018-09-29 15:42:22 +0000 media-gfx/gimp: Remove 2.10.6 in favor of 2.10.6-r1 Closes: https://bugs.gentoo.org/664938 Package-Manager: Portage-2.3.49, Repoman-2.3.10 Signed-off-by: Sebastian Pipping <sping@gentoo.org> media-gfx/gimp/gimp-2.10.6.ebuild | 199 -------------------------------------- profiles/package.mask | 6 -- 2 files changed, 205 deletions(-)
