Date: Sat, 20 Apr 2019 11:32:47 +0000 From: bugzilla-noreply@freebsd.org To: pkg@FreeBSD.org Subject: [Bug 237369] ports-mgmt/pkg: pkg delete removes required NLS directories Message-ID: <bug-237369-32340-Y4afVydtDM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-237369-32340@https.bugs.freebsd.org/bugzilla/> References: <bug-237369-32340@https.bugs.freebsd.org/bugzilla/>
index | next in thread | previous in thread | raw e-mail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237369 --- Comment #2 from Stefan Esser <se@FreeBSD.org> --- Sorry for not making the upgraded port available - after writing the PR I was afraid it could cause problems for users that caused them some effort to understand and fix ... I have just committed the version with NLS files (1.2.8) and have further analyzed the problem. My attempt to fix the issue by adding a @postunexec command failed, since these commands are executed before the directory is removed. (I tried "@postunexec /bin/mkdir -p %%LOCALBASE%%/share/nls/C"). I can work around this issue by adding a preexec command that creates the missing directory, but this will not help other ports that install files into share/nls. The actual problem is that the port uses message catalog files that are meant to be portable to quite a number of platforms. These are named according to typical locale names, but the install script takes care to only install to existing nls directories (does not create directories with names not common for the platform like "en_US.cat" or "en_US.utf8" in the case of FreeBSD). The problem is in the automatic cleanup of empty directories performed by pkg delete if the directory considered is actually a symlink. It would suffice to have pkg keyword like "@precious" or "@keep" to declare some files (or directories, or sub-trees) as not to be cleaned up on uninstall, but I think this is a general problem that should be solved in "pkg". The cause of the problem is that bc.cat gets installed to "share/nls/en_US.US-ASCII", which actually is a symlink to "share/nls/C" (the actual directory). On pkg deletion, the pkg command sees that "share/nls/en_US.US-ASCII" has become empty and tries to delete that directory - but it in fact deletes the symlink target "share/nls/C". If "pkg" was careful to create directories required to install files to before trying to access them, "share/nls/C" could be re-created (in this case by "mkdir share/nls/en_US.US-ASCII/") then the problem could be worked around. But IMHO, "pkg" should not delete empty directories if the last path component is a symlink. I.e. do not perform the equivalent of "rmdir share/nls/en_US-ASCII/" but rather "rmdir share/nls/en_US-ASCII". Deleting the symlink indstead of its target would obviously also be wrong: That would lead to creation of a directory instead of re-creation of the symlink, when a file is to be installed within ... IMHO there is a mis-match between "rmdir share/nls/en_US.US-ASCII/" and "mkdir -p share/nls/en_US.US-ASCII" (but the problem is in the rmdir, not the mkdir). And there are two solutions (besides adding a keyword like @keep): - Perform both rmdir and mkdir on the target of the symlink. - Perform both rmdir and mkdir on the symlink (and ignore the error for operating on a non-directory). I'd prefer to not delete, since I consider directories below share/nls as "infrastructure", even though they are not covered by an mtree definition (AFAIK). Having "share/nls/C" re-appear after a mkdir "share/nls/en_US.US-ASCII/" seems surprising - but perhaps the idea to have "POSIX", "en_US.US-ASCII", and "en_US.US_ASCII" all being symlinks to "nls/share/C" is the real problem (with "en_US.US_ASCII" being an outlier anyway - it does not exist for any other "en" region. And BTW: It is funny to see that there is only "en_IE.UTF-8" and no directory for the corresponding ISO locales or US-ASCII. Maybe this was an oversight when this locale was created? -- You are receiving this mail because: You are the assignee for the bug. You are on the CC list for the bug.help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-237369-32340-Y4afVydtDM>