Bug 246102 - Mk/Uses/gnome.mk: INSTALLS_ICONS makes packages that will destroy icon-theme.cache files on deinstallation (gnome-post-icons: target generates unsuitable PLIST @rmtry)
Summary: Mk/Uses/gnome.mk: INSTALLS_ICONS makes packages that will destroy icon-theme....
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Ports Framework (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: Port Management Team
Depends on:
Reported: 2020-05-01 19:22 UTC by Matthias Andree
Modified: 2021-11-08 14:29 UTC (History)
4 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Matthias Andree freebsd_committer 2020-05-01 19:22:00 UTC
I am hijacking and answering madpilot@s post to freebsd-ports today:

Am 01.05.20 um 19:49 schrieb Guido Falsi:
> hi,
> While testing an update to xfce ports I have got this error in poudriere:
> =>> Checking for extra files and directories
> =>> Error: Files or directories removed:
> share/icons/hicolor/icon-theme.cache
> And could not find any cause for it.
> This file should be managed by the INSTALLS_ICONS port variable, which
> adds post-install and post-deinstall commands.
> My suspect is the post-deinstall command is not being run properly for
> some reason causing this error.
> Could this be correct? How can I verify this?
You're hunting the wrong fault, and poudriere reports a genuine bug (which is not in your package).

Read again: the complaint is that the port deinstallation REMOVES (not: LEAVES BEHIND) the prior icon-theme.cache.

I've debugged this, the INSTALLS_ICONS from Mk/Uses/gnome.mk adds a @rmtry (i. e. delete, but don't complain if missing) for the cache file, and topmost in the PLIST, so the deinstallation of ANY package using that macro will first update and then nuke the cache file. Proof below.

Conclusion: Mk/Uses/gnome.mk is broken (in particular the gnome-post-icons: target). Here's how:

# pkg -ddd delete xfce4-taskmanager # (was version 1.2.3):

> [...]
> DBG(1)[59116]> Deleting file: 'usr/local/share/locale/zh_TW/LC_MESSAGES/xfce4-taskmanager.mo'
> DBG(1)[59116]> Adding to deletion usr/local/share/locale/zh_TW/LC_MESSAGES/
> [1/1] Deleting files for xfce4-taskmanager-1.2.3... done
> DBG(3)[59116]> Scripts: executing
> --- BEGIN ---
> set -- xfce4-taskmanager-1.2.3
> /usr/local/bin/gtk-update-icon-cache -q -f /usr/local/share/icons/hicolor 2>/dev/null || /usr/bin/true
> Scripts: --- END ---
> DBG(3)[59119]> Scripts: executing lua
> --- BEGIN ---
>         file = pkg.prefixed_path("share/icons/hicolor/icon-theme.cache")
>         -- ignore the return value and the error
>         ret, err = os.remove(file)
> Scripts: --- END ---

and after that, /usr/local/share/icons/hicolor/icon-theme.cache is missing.

Meaning that the deinstallation of ANY (but the last installed) package that uses INSTALLS_ICONS deletes the icon-theme.cache files in all directories where they had placed icons.
Comment 1 Antoine Brodin freebsd_committer 2020-05-01 19:28:49 UTC
I think it's a regression from the @rmtry implementation in shell to an implementation in lua,  the ordering is no longer the same
Comment 2 commit-hook freebsd_committer 2020-05-01 19:39:52 UTC
A commit references this bug:

Author: antoine
Date: Fri May  1 19:39:26 UTC 2020
New revision: 533583
URL: https://svnweb.freebsd.org/changeset/ports/533583

  Revert r533339,  there is a regression in ordering

  With hat:	portmgr
  PR:		246102

Comment 3 Matthias Andree freebsd_committer 2020-05-02 09:39:34 UTC

I understand that this was just a revert to keep things simple.

But calling || /usr/bin/true as external command through the ...fork/execve cycle is irritating to me. The AND-OR list (||) clearly indicates that a shell is being used, and why are we using an external command rather than the shell built-in true or :?