|Summary:||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)|
|Product:||Ports & Packages||Reporter:||Matthias Andree <mandree>|
|Component:||Ports Framework||Assignee:||Port Management Team <portmgr>|
|Severity:||Affects Many People||CC:||gnome, lantw44, madpilot, ports-bugs|
Description Matthias Andree 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)> Deleting file: 'usr/local/share/locale/zh_TW/LC_MESSAGES/xfce4-taskmanager.mo' > DBG(1)> Adding to deletion usr/local/share/locale/zh_TW/LC_MESSAGES/ > [1/1] Deleting files for xfce4-taskmanager-1.2.3... done > DBG(3)> 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)> 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 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 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 Log: Revert r533339, there is a regression in ordering With hat: portmgr PR: 246102 Changes: head/Keywords/rmtry.ucl
Comment 3 Matthias Andree 2020-05-02 09:39:34 UTC
Antoine, 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 :?