Il 22/02/23 19:46, Kevin Fenzi ha scritto: > On Wed, Feb 22, 2023 at 08:37:00AM +0000, Richard W.M. Jones wrote: >> It's also been a long time since I've seen any benefit. >> >> Can anyone summarise quickly why delta RPMs don't work? It seems like >> they "obviously" should be possible, because there must be a lot of >> commonality in the content of adjacent RPM versions ... > pungi creates composes. It does this by asking koji for 'whats the > latest rpm tagged into this tag'. It then operates on those packages. > It has little concept of other repos/things other than koji. > > So, in order to do what might be expected it would have to: > > * query koji/download things as it does now. > * copy in the current repos > * possibly prune based on something (only 2 copies, only X days old) > * then go on with it's repo creation, etc. > So, does that mean that every time a compose is performed pungi downloads all RPMs tagged with a specific tag in a directory and then it operates on those to create repository metadata? Or it just downloads the rpms headers, or whatever?
Can we have a persistent compose root directory as base, then download the latest builds (if newer), do the pruning "based on something", create the repo and save the state as the base for the next run? Or will that eat way too much disk space? On the other hand we could save bandwith because we would not download all the rpms which were not updated from the previous run... what's more valuable for our infrastructure, disk space or network bandwith usage? Mattia _______________________________________________ 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
