FS#76250 - [filesystem] should not need /usr/local/share/man to exist as a symbolic link

Attached to Project: Arch Linux
Opened by Gaël Bonithon (shoryuken) - Thursday, 20 October 2022, 06:46 GMT
Last edited by Buggy McBugFace (bugbot) - Saturday, 25 November 2023, 20:14 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Sébastien Luttringer (seblu)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

filesystem needs /usr/local/share/man to exist as a symbolic link, it shouldn't (/usr/local is for user installs).

If /usr/local/share/man exists as a directory:
error: extract: not overwriting dir with file /usr/local/share/man
error: problem occurred while upgrading filesystem
error: could not commit transaction
error: failed to commit transaction (transaction aborted)
Errors occurred, no packages were upgraded.

If /usr/local/share/man does not exist:
warning: could not get file information for usr/local/share/man

Additional info:
* package version(s): 2021.12.07-1 -> 2022.10.18-1

Steps to reproduce: Install filesystem 2022.10.18-1
This task depends upon

Closed by  Buggy McBugFace (bugbot)
Saturday, 25 November 2023, 20:14 GMT
Reason for closing:  Moved
Additional comments about closing:  https://gitlab.archlinux.org/archlinux/p ackaging/packages/filesystem/issues/2
Comment by Toolybird (Toolybird) - Thursday, 20 October 2022, 07:16 GMT
Related  FS#57884  (Dupe?)
Comment by Gaël Bonithon (shoryuken) - Thursday, 20 October 2022, 07:39 GMT
Not really a dupe I think, anyway you should clearly not overwrite, or even try to overwrite what a user puts in his /usr/local dir.
The warning above is ok, but not the errors.
Comment by Doug Newgard (Scimmia) - Thursday, 20 October 2022, 08:44 GMT
Packages shouldn't be putting things in /usr/local/, so the error would never happen.
Comment by Toolybird (Toolybird) - Friday, 21 October 2022, 21:49 GMT
> /usr/local is for user installs

Sure, but messing with the filesystem as supplied by the filesystem pkg cannot be supported.
Comment by Sergio Callegari (callegar) - Sunday, 02 July 2023, 08:13 GMT
The current situation makes it hard to use `stow` to manage local packages.

This is because when you use an install script to install a package `foo` to a stow directory `/usr/local/stow/foo`, you change the PREFIX to `/usr/local/stow/foo`. As a consequence the install redirects what normally would go to `/usr` there. This means that you'll typically get your man pages in `/usr/local/stow/foo/share/man`, not in `/usr/local/stow/foo/man`.

Unfortunately, as soon as you have `/usr/local/stow/foo/share/man`, in arch and derivatives stow will error out when trying to perform its task because `/usr/local/share/man` exists as a symlink.

Yes, you can tweak the install script to force the man pages to go to `/usr/local/stow/foo/man`, but changing the PREFIX only would be much better.

It has been argued that “Using /usr/local for GNU stow is *not* obligatory” so supporting it is not a concern. However, /usr/local is the system administrator playground, so it would be better not to actively make it harder to manage it with whatever tool deemed appropriate.

Assuring that the filesystem package can tolerate `/usr/local/share/man` being a directory and `/usr/local/man` being a symlink to it would be appreciable. In fact, it would be great if in the future the filesystem package could set up systems this way rather than the other way round. However, the latter is not the primary concern.
Comment by Toolybird (Toolybird) - Sunday, 02 July 2023, 08:14 GMT
As per  FS#17534 , an upgrade path is currently not possible if /usr/local/man is populated:

(1/1) checking for file conflicts
error: failed to commit transaction (conflicting files)
filesystem: /usr/local/man exists in filesystem
Errors occurred, no packages were upgraded.

This is a pacman limitation. Some large hoops could theoretically be jumped through (an install scriptlet maybe?) but honestly, who is going to implement such a thing when nobody cares about obscure niche cases? The "GNU stow managing pkgs in /usr/local" argument is weak IMHO.

If there is no interest from the PM, this will again be closed.
Comment by Sergio Callegari (callegar) - Sunday, 02 July 2023, 08:20 GMT
In the meantime I have also asked if this can be fixed the `stow` side at https://savannah.gnu.org/bugs/?64372.
Still, having the possibility to make the filesystem set up in `/usr/local` as consistent as possible to that in `\usr` would generally be a plus IMHO.
Comment by Sébastien Luttringer (seblu) - Tuesday, 15 August 2023, 11:09 GMT
filesystem is currently in charge of initializing the /usr/local with well-known directories.

The FHS[1] states that certain folders must be present in /usr/local and that they must be safe from being overwritten by software update. I remind you that we follow the FHS in a relaxed way, but I will therefore move the creation of /usr/local in an install script so that the updates of filesystem no longer take care of what happens in /usr/local.
It will also be the occasion to symlink /usr/local/sbin to bin

[1] https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s09.html