I have progressed to the point where I just have to rebuild chromium.
During the building of Chromium, a tool linked with libxml2 was created, and in
order to use it, a libmap for that was also needed.
Make sure that the libmap is applied to WRKDIR directory.
[/usr/ports/]
libxml2.so.16 libxml2.so.16
And since that was successfully completed, I removed all libmaps related to
libxml2.so.2.
Then, I terminated all programs linked to libxml2.so.16 and rebooted the
service.
The access time of libxml2.so.2 has not changed, so everything must have been
completed :)
On 2025/07/01 23:36, Tomoaki AOKI wrote:
It would be because the directory was first introduced to preserve old
libraries.
If I'm not wrong, shared-opened shlibs can be deleted by
root, but of course unsafe on reloads. So possibly to-be-deleted shared
objects are moved to there (or somewhere else) temporarily and actually
deleted once confirmed to be safe.
Portupgrade preserves old shared objects to there by default maybe not
to stop anything depending on it but not yet rebuilt, OTOH, portmaster
doesn't preserve shared objects by default, maybe to be more secure.
It seems to be related to the bump of portrevision of the consumer port when
the library version changed.
Recent updates regarding library dependencies in pkg seem to have brought it
closer to its original form.
IIRC, OS/2 locked in-use DLL files, which makes it impossible to
upgrade by service packs in-place. So it had mechanism to use
a specific list of to-be-replaced files and also had device (filter)
driver that handle the replacements on boot. But cannot find the
records, as it was (IIRC) only temporarily added to config.sys on
applying service pack (CSD) before reboot and removed on cleanup phase.
So my old backup doesn't have any config.sys containing it.
It is considered to be within the capabilities of the file system.
For example, by unlinking a temporary file immediately after opening it, only
the process that opened it will be able to use it.
In the Windows side as well, it is often not allowed to interfere with the
files being used :)
Templates/BSD.local.dist will try to delete this directory if it is empty :)
It would be sane way. ;-)
"pkg info -R pkg" shows that the directory of .../compat/pkg is registered, but
is it the case that the purpose is to delete the directory during deinstallation, and
that there is no need to maintain its existence?
Regards.
