On Tue, Aug 5, 2025 at 12:46 AM Panu Matilainen <pmati...@redhat.com> wrote: > > On 7/29/25 2:13 AM, Neal Gompa wrote: > > On Mon, Jul 28, 2025 at 6:30 PM Andrew Lutomirski <l...@mit.edu> wrote: > >> > >>> On Jul 24, 2025, at 7:02 PM, Aoife Moloney via devel-announce > >>> <devel-annou...@lists.fedoraproject.org> wrote: > >>> > >>> Wiki - > >>> https://fedoraproject.org/wiki/Changes/Hardlink_identical_files_in_packages_by_default > >>> Discussion thread - > >>> https://discussion.fedoraproject.org/t/f43-change-proposal-hardlink-identical-files-in-packages-by-default-self-contained/160769 > >>> > >>> This is a proposed Change for Fedora Linux. > >>> This document represents a proposed Change. As part of the Changes > >>> process, proposals are publicly announced in order to receive > >>> community feedback. This proposal will only be implemented if approved > >>> by the Fedora Engineering Steering Committee. > >>> > >>> == Summary == > >>> A post-build step is added to the package build macros to > >>> automatically hardlink all identical files under `/usr`. Previously, > >>> this was done in some packages and now it's done everywhere by > >>> default. > >> > >> Almost every time I encounter a hard link, I think it wants to be a > >> reflink instead. And this is very much an example of this! > >> > >> Hardlinks are footguns. If you modify them, you get unexpected > >> results. (Yes, I know you're not supposed to modify a file that rpm > >> installed. People do it anyway.) If you are writing a tool that > >> modifies one copy of a pair of files that are actually hardlinks to > >> each other, you get awkward results. Even from a filesystem > >> implementation perspective, hardlinks are kind of gross, and if I were > >> designing a filesystem from scratch, I would probably not support > >> them, or at least not as a first-class feature. > >> > >> Other than the lack of rpm support, is there any good reason to use > >> hardlinks instead of reflinks? Reflinks actually do what one would > >> want here -- the act like two separate files (which is what the > >> package expects) but they share storage. > >> > > > > Reflink support has long since been blocked on upstream progress on > > RPMCoW[1]. I really do wish this was further along, I really love this > > feature in CentOS Hyperscale. > > reflink() does not equal RPMCoW. > > RPMCoW is this controversial and complicated thing that involves > transcoding rpm packages into unverifiable blobs and then reflinks from > those. It's been explicitly NAK'ed upstream, multiple times now. > > There's nothing evil or controversial about reflink as such, but using > it in rpm context is not straightforward. >
Transcoding would not be required if the RPM format itself was made up of reflinkable items. Unless you're open to changing the RPM archive format, there are not a lot of other options. -- 真実はいつも一つ！/ Always, there's only one truth! -- _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
