[Bug 237369] ports-mgmt/pkg: pkg delete removes required NLS directories

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237369

--- Comment #2 from Stefan Esser <se at 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.