I don't know if this post makes sense at all, but I'll share some thoughts about how we make composes for Fedora repositories. Maybe someone could clarify some things to me and I'll discover my knowledge is wrong.
So, I was looking at what I consider an inefficient use of disk space for our repositories. At the best of my knowledge, a compose is made by taking all latest builds tagged in a specific koji tag (say f43-updates), copying the RPMs in a folder and generating the repository metadata used by dnf to list and find those builds.
What I consider inefficient is that every subsequent compose will copy the same RPM again if the package got no new builds. So, for example in the 20260610 compose [1] we have have: /compose/updates/Fedora-43-updates-20260610.0/compose/Everything/x86_64/os/Packages/0 with a 0ad-data-0.28.0-1.fc43.noarch.rpm which is 1.5GB.
The next day we have 20260611 compose [2] with /compose/updates/Fedora-43-updates-20260611.0/compose/Everything/x86_64/os/Packages/0 with the same 0ad-data-0.28.0-1.fc43.noarch.rpm which occupy another 1.5GB.
And so on. Can't we just use a single 'compose/Everything/x86_64/os/Packages/' directory for storing RPMs with multiple 'compose/Everything/x86_64/os/repodata' for the repodata? Is it just the way we do composes, a limitation of RPM/pungi/whatever or is there a compelling reason to do that (and I'm just barking at the moon)?
My idea is that if we could save those resources we may think at creating composes with the latest 2 or 3 builds of a package in that Koji tag, so that a 'dnf downgrade' command can work as expected.
Mattia
[1] https://kojipkgs.fedoraproject.org/compose/updates/Fedora-43-updates-2026061... [2] https://kojipkgs.fedoraproject.org/compose/updates/Fedora-43-updates-2026061...
On Thu, 2026-06-11 at 15:36 +0000, Mattia Verga via devel wrote:
I don't know if this post makes sense at all, but I'll share some thoughts about how we make composes for Fedora repositories. Maybe someone could clarify some things to me and I'll discover my knowledge is wrong.
So, I was looking at what I consider an inefficient use of disk space for our repositories. At the best of my knowledge, a compose is made by taking all latest builds tagged in a specific koji tag (say f43-updates), copying the RPMs in a folder and generating the repository metadata used by dnf to list and find those builds.
What I consider inefficient is that every subsequent compose will copy the same RPM again if the package got no new builds. So, for example in the 20260610 compose [1] we have have: /compose/updates/Fedora-43-updates-20260610.0/compose/Everything/x86_64/os/Packages/0 with a 0ad-data-0.28.0-1.fc43.noarch.rpm which is 1.5GB.
The next day we have 20260611 compose [2] with /compose/updates/Fedora-43-updates-20260611.0/compose/Everything/x86_64/os/Packages/0 with the same 0ad-data-0.28.0-1.fc43.noarch.rpm which occupy another 1.5GB.
And so on. Can't we just use a single 'compose/Everything/x86_64/os/Packages/' directory for storing RPMs with multiple 'compose/Everything/x86_64/os/repodata' for the repodata? Is it just the way we do composes, a limitation of RPM/pungi/whatever or is there a compelling reason to do that (and I'm just barking at the moon)?
My idea is that if we could save those resources we may think at creating composes with the latest 2 or 3 builds of a package in that Koji tag, so that a 'dnf downgrade' command can work as expected.
They're not copied. They're hardlinked.
https://forge.fedoraproject.org/pungi/pungi/src/commit/6989c9ede0881ecba8798...
The default link_type is hardlink-or-copy:
https://forge.fedoraproject.org/pungi/pungi/src/commit/6989c9ede0881ecba8798...
and we do not override this in Fedora config. So packages are hardlinked unless they cannot be for some reason (filesystem limitation, usually) in which case *only* they're copied.
Dne 11. 06. 26 v 5:36 odp. Mattia Verga via devel napsal(a):
My idea is that if we could save those resources
BTW if you think about improvements there is a mature project that took hundreds of such improvements and packed it together:
Copr just started using this as storage backend.
-
Adam Williamson -
Mattia Verga -
Miroslav Suchý