On Thu, Aug 12, 2021 at 01:00:26AM +0200, Fabio Valentini wrote: ...snip... > > I wonder why there's so few drpms in most transactions I see? > Does this system not prioritize packages, like, those that are > installed on all variants, or installed by default on Workstation?
So, it's complicated, but let me try... drpms are generated by createrepo_c at the same time it's generating the repodata for a repo. You can pass it things to tell it how many deltas to make and where to find old rpms, etc. When an updates push happens, bodhi fires off a pungi job for that version/repo (ie, say fedora-34-updates). pungi sees that as a new compose. It gathers all the things from koji in f34-updates tag and sets things up. When it runs createrepo_c it only has access to: the current rpms, the rpms in the current 'updates/34' repo and thats it. So, the only drpms we currently get are when there's a update already in stable updates and we have a new update of the same package going stable. But then it also only keeps it for that one updates push. On the next push things start over and there's not any 'old' package in the updates repo, so no drpm is made. Lots of things make this not very flexable: * only can make drpms at createrepo_c run time, this means you can't do them later/on the side/keep previous ones around/etc. * pungi doesn't have access to older rpms at the right time to generate more and has no way to keep them accross pushes. We could do lots of things to fix this, but would need work: * if we had a standlone tool that could generate arbitrary drpms and 'insert' them into repodata we could run those seperate from updates composes and keep more of them. Of course repodata signing would complicate this. * If dnf could look for drpms in some standard 'other' repo when enabled we could perhaps just generate those repos out of band. It's also not clear what would be the ideal amount/kind of drpms to make... GA to current updates? That plus last update? That plus last 2 updates? > > The way it is right now, I could turn drpms off entirely, and probably > not change the download size at all (because savings are small and are > cancelled out by failure cases), and save some CPU time. Is it really > worth it keeping all that infrastructure for drpms around, if they > doesn't actually provide any benefit wrt. amount of data to download, > and actually increases CPU usage? I recall when we made them enabled by default. I heard a number of users say that that specifically was why they decided to run Fedora. ;) Of course times may well have changed. kevin
signature.asc
Description: PGP signature
_______________________________________________ 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 on the list, report it: https://pagure.io/fedora-infrastructure
