should not need /usr/local/share/man to exist as a symbolic link
| Task Info (Flyspray) | |
|---|---|
| Opened By | Gaël Bonithon (shoryuken) |
| Task ID | 76250 |
| Type | Bug Report |
| Project | Arch Linux |
| Category | Packages: Core |
| Version | None |
| OS | All |
| Opened | 2022-10-20 06:46:53 UTC |
| Status | Assigned |
| Assignee | Sébastien Luttringer (seblu) |
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
Activity
added priority3-normal scopebug severity4-low statusconfirmed labels
Added 2022-10-20 07:16:31 UTC - Commented by Toolybird (Toolybird)
Related FS#57884 (Dupe?)
Added 2022-10-20 07:39:08 UTC - Commented by Gaël Bonithon (shoryuken)
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.
Added 2022-10-20 08:44:51 UTC - Commented by Doug Newgard (Scimmia)
Packages shouldn't be putting things in /usr/local/, so the error would never happen.
Added 2022-10-21 21:49:36 UTC - Commented by Toolybird (Toolybird)
/usr/local is for user installs
Sure, but messing with the filesystem as supplied by the filesystem pkg cannot be supported.
Added 2023-07-02 08:13:23 UTC - Commented by Sergio Callegari (callegar)
The current situation makes it hard to use
stowto manage local packages.This is because when you use an install script to install a package
footo 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/usrthere. 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/manexists 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/manbeing a directory and/usr/local/manbeing 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.Added 2023-07-02 08:14:29 UTC - Commented by Toolybird (Toolybird)
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.
Added 2023-07-02 08:20:31 UTC - Commented by Sergio Callegari (callegar)
In the meantime I have also asked if this can be fixed the
stowside at https://savannah.gnu.org/bugs/?64372. Still, having the possibility to make the filesystem set up in/usr/localas consistent as possible to that in\usrwould generally be a plus IMHO.Added 2023-08-15 11:09:08 UTC - Commented by Sébastien Luttringer (seblu)
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
assigned to @seblu
assigned to @dvzrv
I'm going to pipe up here too. /usr/local/* should not be in the filesystem package, whatever the FHS says... providing some dirs set up by default is fine but then having them hard-locked in the package after that when the user/owner should be free to maintain /usr/local/* themselves (that's the original point)... is imho not right.
