Re: deltarpm usefulness?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux