Fedora 44 hardlinks identical files under /usr <https://fedoraproject.org/wiki/Changes/Hardlink_identical_files_in_packages_by_default>. An example is perl-Dist-Zilla-Plugin-Git-tests-2.052-1.fc44.noarch built from perl-Dist-Zilla-Plugin-Git component <https://kojipkgs.fedoraproject.org//packages/perl-Dist-Zilla-Plugin-Git/2.052/1.fc44/noarch/perl-Dist-Zilla-Plugin-Git-tests-2.052-1.fc44.noarch.rpm>. Then rpmlint-2.7.0-8.fc44.noarch spits a lot of warnings like this: perl-Dist-Zilla-Plugin-Git-tests.noarch: W: cross-directory-hard-link /usr/libexec/perl-Dist-Zilla-Plugin-Git/corpus/commit-build-src-as-parent/Changes /usr/libexec/perl-Dist-Zilla-Plugin-Git/corpus/check/Changes If this Fedora Change is in effect, Fedora's rpmlint should silent these warnings.
$ rpmlint -e cross-directory-hard-link cross-directory-hard-link: File is hard linked across directories. This can cause problems in installations where the directories are located on different devices. Zbyszek, are you sure this is safe nowadays? What if my /usr/foo and /usr/bar are different devices and there is a hardline between files in them. Will RPM not fail? If not, we should bring this rpmlint upstream to remove that warning entirely. If it is a problem, perhaps the change needs to address that. AFAIK it only concerns itself with hardlinks bwteen different subpackages, not between different devices.
rpm will indeed fail if it tries to unpack an rpm with hardlinks across mount points. (Verified this now with rpm-5.999.92-1.fc44.) But I think that this is not something that we should support. Many packages hardlink files to save space and this has not been reported as a bug. We are not hardlinking arbitrary files, just packaged contents of a single package under /usr. I think rpmlint should drop the warning.
I don't agree that this is not something that we should support. This was not explicitly mentioned in the change proposal and is a serious downside that might need more discussion. For example, in the related Python BRP, we only hardlink .pyc files that are located in the same directory.
The python scripts did indeed only link some files. But other packages did the linking across directories. We can a) forbid linking across directories and undo the whole thing, and also "fix" other packages b) make rpm handle this properly, i.e. just write out the file fully if it cannot link c) ignore the whole thing for now. I think c) is the most reasonable approach. So far we got an rpmlint warning, but not real reports that this is a problem for anybody, or that anyone even noticed this.
b) would be nice. Should we bring this up on the devel mailing list instead of rpmlint bugzilla?
I'll reassign this to rpm to gather comments. Please note that I'm not saying that this is something that I consider important to fix quickly (or even at all).
Mm. I would say rpm's hardlink handling is not up to the task at hand. IIRC it can only handle one set of hardlinks at a time, and the wider the links are spread, the chances of hitting interleaved hardlink sets increases significantly. The result would be broken installs. To handle copying if linking fails requires a fair amount of extra bookkeeping because it can't copy at the time of the link failure, it needs to track the failed links and then copy once the entire set has been laid down. In what is a pretty tricky piece of code to start with, managing skipped files and all that. I can make an upstream ticket of that, but I don't know when we would be able to do it, the team being down to just two now.
So, what do we do with this bug? For now, I'd consider rpmlint's warning quite appropriate because rpm cannot guarantee hardlinks across multiple directories. I don't see this getting fixed upstream in the immediate future either.
I stand by my reply above: > I think c) [ignore the whole thing for now] is the most reasonable approach. So far > we got an rpmlint warning, but not real reports that this is a problem for anybody, > or that anyone even noticed this.
I'll pass back to rpmlint then, because if its supposed to be okay then rpmlint shouldn't warn. I'll also note that I do not think this is a safe thing to do as long as rpm does not support resolving hardlinked files across filesystems.
I do not think this is a safe thing either. I don't feel comfortable just silencing that rpmlint report. Should we bring this up on the devel mailing list instead of rpmlint bugzilla?
I understand that there is a bit of an impasse here between two points of view, but the status quo isn’t exactly satisfactory. I see these messages very frequently in my own packages (which I try to keep “rpmlint-clean” with .rpmlintrc files as necessary) and in package reviews. They currently seem to constitute the main source of “noise” in rpmlint output. Surely creating these hardlinks can’t be simultaneously safe enough to do automatically for every package, and also dangerous enough to barrage rpmlint users with warnings about them.
> Surely creating these hardlinks can’t be simultaneously safe enough to do automatically for every package, and also dangerous enough to barrage rpmlint users with warnings about them. Surely :) I still think this is unsafe. But not doing anything won't change that, so let's filter the noise. Packagers cannot fix those problems anyway, unless they selectively opt out, which is not the desired outcome.
FEDORA-2026-dbae420d75 (rpmlint-2.8.0-2.fc44) has been submitted as an update to Fedora 44. https://bodhi.fedoraproject.org/updates/FEDORA-2026-dbae420d75
FEDORA-2026-dbae420d75 (rpmlint-2.8.0-2.fc44) has been pushed to the Fedora 44 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-d1eacaf1e4 (rpmlint-2.8.0-2.fc43) has been submitted as an update to Fedora 43. https://bodhi.fedoraproject.org/updates/FEDORA-2026-d1eacaf1e4
FEDORA-EPEL-2026-6ade0da191 (rpmlint-2.8.0-2.el10_2) has been submitted as an update to Fedora EPEL 10.2. https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-6ade0da191
FEDORA-2026-55dff742bc has been pushed to the Fedora 42 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-55dff742bc` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-55dff742bc See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-EPEL-2026-6ade0da191 has been pushed to the Fedora EPEL 10.2 testing repository. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2026-6ade0da191 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-d1eacaf1e4 has been pushed to the Fedora 43 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-d1eacaf1e4` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-d1eacaf1e4 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2026-d1eacaf1e4 (rpmlint-2.8.0-2.fc43) has been pushed to the Fedora 43 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-EPEL-2026-6ade0da191 (rpmlint-2.8.0-2.el10_2) has been pushed to the Fedora EPEL 10.2 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2026-55dff742bc (rpmlint-2.8.0-2.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.