packaging-committee

#1355 Drop historical rule for canonical file locations
Merged by ngompa. Opened by zbyszek.
zbyszek/packaging-committee drop-rule-about-canonical-file-locations  into  master

Download 1355.patch

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.

I don't disagree, but making a change like this requires coordination between packagers. Is that coordination going to be wholly contained in the unification change or is that going to be handled separately? And if the latter, where is that going to be tracked?

Might as well use bold MUST here.

And bold MAY here.

rebased onto 87905972a23549f0696b82340b54e17fb444212a

Force-pushed with more markup.

making a change like this requires coordination between packagers. Is that coordination going to be wholly contained in the unification change or is that going to be handled separately? And if the latter, where is that going to be tracked?

My thinking here is that we'll use the usual rule that existing packages do not have to be updated immediately when Guidelines change. When somebody decides to clean this up in a given package, they'll need to check what, if anything, uses the old Requires and then make a choice, whether to fix the consumer or to provide a Provides for the old name. For the packages which I need to touch for the sbin-merge changes, I'd try to clean them up, but I don't think we need to do that in all cases.

My thinking here is that we'll use the usual rule that existing packages do not have to be updated immediately when Guidelines change. When somebody decides to clean this up in a given package, they'll need to check what, if anything, uses the old Requires and then make a choice, whether to fix the consumer or to provide a Provides for the old name. For the packages which I need to touch for the sbin-merge changes, I'd try to clean them up, but I don't think we need to do that in all cases.

It seems to me that at least a little more coordination than that would be warranted. Do we even have a list of packages that would need to be changed, so that this can all be tracked?

Do we even have a list of packages that would need to be changed, so that this can all be tracked?

I tried to figure this out.

The list of all files in /bin and /sbin listed in package payloads:

nfs-utils: /sbin/mount.nfs
nfs-utils: /sbin/mount.nfs4
nfs-utils: /sbin/nfsdcltrack
nfs-utils: /sbin/rpc.statd
nfs-utils: /sbin/umount.nfs
nfs-utils: /sbin/umount.nfs4
glibc: /sbin/ldconfig
ocfs2-tools: /sbin/debugfs.ocfs2
ocfs2-tools: /sbin/defragfs.ocfs2
ocfs2-tools: /sbin/fsck.ocfs2
ocfs2-tools: /sbin/mkfs.ocfs2
ocfs2-tools: /sbin/mount.ocfs2
ocfs2-tools: /sbin/mounted.ocfs2
ocfs2-tools: /sbin/o2cb
ocfs2-tools: /sbin/o2cb.init
ocfs2-tools: /sbin/o2cb_ctl
ocfs2-tools: /sbin/o2cluster
ocfs2-tools: /sbin/o2image
ocfs2-tools: /sbin/ocfs2.init
ocfs2-tools: /sbin/ocfs2_hb_ctl
ocfs2-tools: /sbin/tunefs.ocfs2
ocfs2-tools: /sbin/debugfs.ocfs2
ocfs2-tools: /sbin/defragfs.ocfs2
ocfs2-tools: /sbin/fsck.ocfs2
ocfs2-tools: /sbin/mkfs.ocfs2
ocfs2-tools: /sbin/mount.ocfs2
ocfs2-tools: /sbin/mounted.ocfs2
ocfs2-tools: /sbin/o2cb
ocfs2-tools: /sbin/o2cb.init
ocfs2-tools: /sbin/o2cb_ctl
ocfs2-tools: /sbin/o2cluster
ocfs2-tools: /sbin/o2image
ocfs2-tools: /sbin/ocfs2.init
ocfs2-tools: /sbin/ocfs2_hb_ctl
ocfs2-tools: /sbin/tunefs.ocfs2

Unless I messed up something in the scripts, it's just three packages.
I can file pull requests against all three myself.
Edited by zbyszek

Pull requests to make the packages conform to the updated guidelines:
https://src.fedoraproject.org/rpms/glibc/pull-request/91
https://src.fedoraproject.org/rpms/ocfs2-tools/pull-request/2

For nfs-utils, I cannot file a PR: https://pagure.io/fedora-infrastructure/issue/11876.
Patch: https://in.waw.pl/~zbyszek/fedora/0001-Move-binaries-to-_sbindir-adjust-paths-for-merged-sb.patch
Edited by zbyszek

The coordination was done as requested, i.e. I filed patches for all packages that I found that use the old scheme. (There's also nilfs-utils, which the initial repoquery missed. I'm not sure if I mistyped something or if repoquery didn't return the full results.) If there are any more that I somehow missed, I can update them too, the procedure is very simple.

Can we merge this now to move things forward?

rebased onto d346c98c21395b22e231ac479e5f3112883fa963

We will need discuss and vote on it first. I'll throw in my +1 vote now; if others want to do the same then they're welcome to do so; otherwise we should hopefully be meeting tomorrow.

Metadata Update from @tibbs:
- Pull-request tagged with: meeting

rebased onto b053f9070fc9bb4e8baa6993caff2bcbd2881300

rebased onto 2fe6a793b9839ea7240d74d4b3a90f35bc5b05e2

Pull-Request has been merged by ngompa

FTR, PRs that implement the change:
https://src.fedoraproject.org/rpms/glibc/pull-request/91
https://src.fedoraproject.org/rpms/ocfs2-tools/pull-request/2
https://src.fedoraproject.org/rpms/nfs-utils/pull-request/15
https://src.fedoraproject.org/rpms/nilfs-utils/pull-request/1
https://src.fedoraproject.org/rpms/glusterfs/pull-request/9
Metadata
None

meeting

Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.