When an install action invokes a post-install script to install a shell link, (a.k.a. shortcut), and a complementary pre-remove script to delete it, the post-install action succeeds, but the pre-remove action fails. Consequently, any shell link created at package installation time, remains in place after subsequent package removal, until the user deletes it manually.
The fundamental problem here is that the
unlink.js
helper, which is invoked to remove the links, performs a lexical comparison between a path name reference passed from the invoking Lua script, and the actual link target path; if these differ, the link will not be deleted.The reference path name, passed from the Lua script is not guaranteed to be canonical, (and if derived from mingw-get's
$APPROOT
,$SYSROOT
, or$FOO_SYSROOT
environment variables, it currently will not be), whereas the reference within the existing shell link always is canonical. This introduces an unacceptable probability of a lexical mismatch, resulting in similar probability of failure to remove links.A partial -- and sufficient -- solution is to adapt
unlink.js
, to ensure that both paths in the comparison are reduced to equivalent canonical forms; (this is not particularly difficult to implement). Ultimately, it would be preferable for mingw-get itself to also reduce the values assigned to$APPROOT
,$SYSROOT
, or$FOO_SYSROOT
to equivalent canonical forms, at the outset.I've now committed an update to
unlink.js
, to ensure that path name comparisons of link references are always canonical vs. canonical. I've pushed it to origin, and it will be incorporated in mingw-get-0.6.2.I will not delay release of 0.6.2 for the sake of canonical form assignment to the respective environment variables; this is deferred to [#2058].
Related
Issues: #2058