From 2fe6a793b9839ea7240d74d4b3a90f35bc5b05e2 Mon Sep 17 00:00:00 2001 From: Zbigniew Jędrzejewski-Szmek Date: Apr 18 2024 16:24:51 +0000 Subject: Drop historical rule for canonical file locations rpm uses the location listed in %files as the canonical location of a file. This is the location that must be used in Requires to refer to files. (In other words, even though /bin is a symlink to /usr/bin, and /bin/foo is really /usr/sbin/foo in the file system, if the package has /bin/foo in %files, Requires:/usr/bin/foo is not going to work.) When UsrMove was implemented 10+ years ago, the real locations in the file system were changed from /[b]bin/* to /usr/[b]bin/*, but as a compatibility measure, a packaging rule was introduced where the location reported in %files was supposed to stay unchanged, so that other packages which used file dependencies wouldn't need to be updated. The rule means that the packager needs to figure out where the file was located "historically" and make %files conform to that. This obviously made the transition easier, but I think it's time to retire this rule. In fact, I think the rule has been mostly forgotten, because it doesn't seem to be widely known or followed and many important packages violate it (for example util-linux, systemd). In fact the rule now it makes the life of packagers harder, because they cannot just check where the file is located, they need to do the dance where they check the canonical location of the file: rpm -ql $(rpm -qf /usr/sbin/ifconfig)|grep sbin/ifconfig We can make packaging easier by removing the rule. It's possible that some packages using file dependencies will need to be adjusted, but it's probably not many and it should be simple to fix them. Once the rule is removed from Packaging Guidelines, we can simplify packages that still take the extra steps to followed the rule to just list files normally in %files. I noticed this rule when preparing for the unification of /usr/bin and /usr/sbin (https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin). It's not strictly necessary, but I think that if we simplify file locations, it's good to get rid of this old complex rule too. --- diff --git a/guidelines/modules/ROOT/pages/index.adoc b/guidelines/modules/ROOT/pages/index.adoc index 988a295..553a9ef 100644 --- a/guidelines/modules/ROOT/pages/index.adoc +++ b/guidelines/modules/ROOT/pages/index.adoc @@ -683,41 +683,22 @@ So an rpm which specified: would be able to satisfy a file dependency for `+/bin/sh+` but not for `+/usr/bin/sh+`. -As a packager you may need to pay attention -to where other packages expect to find your files. -Things that history has placed into -`+/bin+`, `+/sbin+`, `+/lib+`, or `+/lib64+` -should be listed in the `+%files+` section as being in those directories. -Things that history placed in -`+/usr/bin+`, `+/usr/sbin+`, etc, -should be listed in the `+%files+` section as being in -`+%{_bindir}+`, `+%{_sbindir}+`, etc. -If you feel that there is some historical confusion -as to which directory a program is placed in, -you can use a Virtual Provides to list the alternate path. +Packages **must** use the real filesystem paths in the `+%files+` section. +If other packages have dependencies on a different path +that resolves to the same file, +and it is not convenient to update them to the new path, +packages **may** use a virtual `+Provides+` to list the alternate path. + For instance: [source, rpm-spec] ---- -Provides: %{_sbindir}/ifconfig +Provides: /sbin/ifconfig [...] %files -/sbin/ifconfig +%{_sbindir}/ifconfig ---- -If you are a packager who uses file dependencies -to Require the proper dependencies -then you may need to make sure that the file dependencies -are pointing to the location that the packager of that file specified to rpm. -Here's an example of doing this: - -.... -$ rpm -ql $(rpm -qf /usr/sbin/ifconfig)|grep sbin/ifconfig -/sbin/ifconfig -.... - -So you'd want to use `+Requires: /sbin/ifconfig+` in your spec file. - == Use `+rpmlint+` Run rpmlint on binary and source rpms to examine them for common errors,