[BUG] @standard_dirs is missing /usr/share/applications/ and /usr/share/pixmaps/ (and others owned by filesystem)

[Lolig4]

Describe the bug

The @standard_dirs exclusion list in Alien/Package/Rpm.pm is incomplete. /usr/share/applications/ and /usr/share/pixmaps/ are missing, although both are owned by the filesystem package on Fedora. Nearly every GUI .deb ships a .desktop file and an icon, so the generated RPM claims ownership of two directories that already belong to filesystem.

The 8.95.1 fix itself works — /, /usr/, /usr/bin/ and /usr/share/ are correctly suppressed. The list is just short.

This is easy to miss because RPM only errors when the mode differs. In filesystem, /usr/bin and /usr/lib are 0555 while alien emits 0755, which is the hard conflict from SF ticket #1. /usr/share/applications and /usr/share/pixmaps are 0755 on both sides, so the install succeeds and the wrong ownership stays silent until rpm -e tries to remove a filesystem directory.

Suggested fix — add to @standard_dirs; all verified as filesystem-owned on Fedora 44 via rpm -qf, none currently listed:

"/etc/bash_completion.d/",
"/etc/xdg/autostart/",
"/usr/lib/sysusers.d/",
"/usr/lib/systemd/system/",
"/usr/lib/tmpfiles.d/",
"/usr/libexec/",
"/usr/share/appdata/",
"/usr/share/applications/",
"/usr/share/bash-completion/",
"/usr/share/locale/",
"/usr/share/metainfo/",
"/usr/share/pixmaps/",
"/usr/share/zsh/",

Longer term the list is a static rpmlint/FHS snapshot and will keep drifting. Deriving it from rpm -ql filesystem where rpm is available, with the static list as fallback, would be exact and self-maintaining.

Version, Tool-chain, Operating System

$ alien --version
alien version unknown
(run from a git checkout of master, commit 306c805, via `perl -I. ./alien.pl`)

$ perl -V   # trimmed
Summary of my perl5 (revision 5 version 42 subversion 3) configuration:
  Platform:
    osname=linux
    osvers=6.11.0
    archname=x86_64-linux-thread-multi
    useithreads=define useperlio=define

$ cat /etc/fedora-release
Fedora release 44 (Forty Four)

$ rpm -q rpm filesystem
rpm-6.0.2-1.fc44.x86_64
filesystem-3.18-52.fc44.x86_64

Steps to reproduce

mkdir -p hello-1.0/{DEBIAN,usr/share/applications,usr/share/pixmaps}
cat > hello-1.0/DEBIAN/control <<'CTL'
Package: hello
Version: 1.0
Architecture: amd64
Maintainer: Test <test@example.com>
Description: minimal test package
 Ships a .desktop file and an icon.
CTL
touch hello-1.0/usr/share/applications/hello.desktop hello-1.0/usr/share/pixmaps/hello.png
dpkg-deb --build --root-owner-group hello-1.0 hello_1.0_amd64.deb && rm -rf hello-1.0

perl -I/path/to/alien /path/to/alien/alien.pl -r -g -k hello_1.0_amd64.deb
sed -n '/^%files/,$p' hello-1.0/*.spec

Expected behavior

No %dir entry for a directory owned by the distribution's filesystem package:

%files
"/usr/share/applications/hello.desktop"
"/usr/share/pixmaps/hello.png"

Actual behaviour

Both directories are claimed by the generated package:

%files
%dir "/usr/share/applications/"
"/usr/share/applications/hello.desktop"
%dir "/usr/share/pixmaps/"
"/usr/share/pixmaps/hello.png"

Screenshots/Logs

The two directories are owned by filesystem, with the same mode alien emits — hence no install-time error, just silent double ownership:

$ rpm -qlv filesystem | grep -E ' /usr/(bin|lib|share|share/applications|share/pixmaps)$'
dr-xr-xr-x    2 root root 0 /usr/bin
dr-xr-xr-x    2 root root 0 /usr/lib
drwxr-xr-x    2 root root 0 /usr/share
drwxr-xr-x    2 root root 0 /usr/share/applications
drwxr-xr-x    2 root root 0 /usr/share/pixmaps

For contrast, the same conversion done with Fedora's packaged alien-8.95-30.fc44 (which predates the @standard_dirs fix entirely) fails at install time on the 0555 directories:

  - file /usr/bin from install of <pkg> conflicts with file from package filesystem-3.18-52.fc44.x86_64
  - file /usr/lib from install of <pkg> conflicts with file from package filesystem-3.18-52.fc44.x86_64