On Tue, Jan 05, 2021 at 09:49:59AM +0100, Miroslav Suchý wrote: > Dne 05. 01. 21 v 0:29 Matthew Miller napsal(a): > > So, the first thing we need to do to fix this is move deltarpm creation out > > of the updates process. > > Right. > > > Kevin Fenzi tells me this would mean we'd need a > > separate delta RPMs repo, > > Why? You can do that in the same repo. You just need once per X days/hours run > createrepo_c --deltas --num-deltas X On Tue, Jan 05, 2021 at 06:30:37PM +0100, Daniel Mach wrote: > > To be honest, I don't understand why drpms are related to Pungi at all. > > Deltas are optional, if they're not available, a normal RPM is used. > They can be processed asynchronously (as mentioned earlier in this thread) > and injected in repos once they're ready. > > Please note that we're talking about 74 drpms in F33.x86_64 updates repo: > http://ftp.fi.muni.cz/pub/linux/fedora/linux/updates/33/Everything/x86_64/drpms/ > > Sometimes I'm wondering if it's worth it and if Fedora shouldn't move away > from drpms. so, ok then. I guess people are still confused about this. Here's my attempt to explain in detail how it currently works: When bodhi does an updates push (say for f33-updates), it does a lot of things. It checks the updates that are pending f33 stable updates, it locks them so no one can mess with them in the ui until it's done, it makes sure they are signed, it tells koji to move the tags the packages are tagged into into f33-updates, then it calls pungi to actually do the heavy lifting. This pungi process then talks to koji and says "hey, give me the latest tagged packages for the 'f33-updates' tag signed with key xyz. It puts them in directories for arch and type and such and runs createrepo_c to make the repodata. This is the point where it makes drpms. In order to make a drpm createpo_c needs to know what you want to make drpms for. It also has to have both the OLD and NEW versions available to make the drpm. createrepo_c also makes the normal repodata In our above case pungi has the current repos it's making and the f33-updates repo. Thus all the drpms it can make are ones where a new package version is being added to the repos and there is an older version available in f33-updates. It doesn't have access to all those versions before or after the ones it has. It only has those two. Once pungi is done, bodhi then does more things (emailing people, updating notes, etc) and... importantly, updates the repodata with the security information (so you can know what are security updates, etc). Then, that entire tree is synced to the master mirrors. On the next f33-updates push the entire process runs again. It never _updates_ existing repos, it always creates them. This means that if you have foo-1.0-1 in f33-updates, foo-1.1-1 comes along, it will make a drpm between them, that will exist _only_ on the day it added foo-1.1-1. The next day it will be gone. This is why there are so few drpms. It's only generating them for the things that it could at the time of the last push. So if you happen to update during a day where there were things updated that you have installed you would see the drpms. If you happen to update the next day, you would not. So, my last thought was to teach pungi about all the old updates trees (which are in the same directory as it makes the new one) and have it gather all the old drpms from those and expire them at some configurable time. This would not use more cycles to make them, and would make the chances of a user being able to use them much higher. But I am not sure this is possible/if pungi maintainers are willing to implement this. It would mean that createrepo_c would need to know about those old drpms to add them to metadata. Failing that we could move the drpm creation to another process/repo, but... drpms have to be in the same repodata as the repo they are for right? Or can they be in another one? Hope that clarifies more than it confuses... kevin
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx
