On Tue, Jan 05, 2021 at 08:49:20AM -0500, Neal Gompa wrote: > On Tue, Jan 5, 2021 at 8:34 AM Colin Walters <walters@xxxxxxxxxx> wrote: > > Now speaking of deltas - really delta implementations are going to benefit from a stronger "cadence" to releases, exactly much like what we do for CoreOS (but not Silverblue/IoT) today. The relationship of such a system and Bodhi is...messy. > > ostree deltas are also *much* better than deltarpm in various ways (most notably the CPU intensive part is bsdiff which we only use selectively instead of the whole thing). > > > > Cadence only matters if the infrastructure around delta fetching > requires it to care. In the case of RPM-OSTree and Flatpak, this is > not a problem as long as you're using native OSTree remotes. If you're > using OCI image remotes instead, then you *do* have to care about > cadence because you have to maintain images and generate deltas based > on possible options. The latter option is how we deliver Flatpaks, and > so we have the same problem we have with DeltaRPMs. > > > On the other hand, we really want deltas too for containers; that's https://github.com/containers/image/pull/902 > > > > A very tricky case is the intersection of all of these; for my "dev container"/toolbox on my Silverblue workstation I use a custom container built on a server with all of my tools, but I do often `yum update` inside it since that works incrementally and online. (But I do periodically flush and re-pull) If we implemented container deltas I'd be a lot more likely to use `podman` to update it instead. > > Addressing the underlying issue here: container deltas and OSTree > deltas are considerably worse for constrained bandwidth than RPM > deltas. Outside of the USA (in the general case) and within the USA > (in several parts of the country), it is extremely common to have > extremely limited bandwidth availability and even more common to have > low throughput. As that will basically never change, we have to work > with that framework. > > Regular Fedora variants offer users the ability to pick and choose > updates based on their situation. If DeltaRPMs were implemented in our > infrastructure correctly, those users would be very well-served by > being able to publish a sliding window of the last 30 days of delta > RPM content. What's particularly galling here is that we have all the > necessary inputs to do it, since Koji keeps everything and Bodhi knows > everything that's ever been pushed. It's pretty much a Pungi > restriction that we've never been able to do this properly. Another thought: we could use popcon-like information to generate delta rpms only for N% most popular packages (10%?). This would significantly cut down on the cost of generation, without really affecting average user savings. Yet another reason why popcon would be useful. > To be blunt, I would have never done Zchunk metadata if it was going > to be used as a tool to kill DeltaRPMs. I firmly believe we need both > to have a comprehensive offering that accommodates the needs of Fedora > users across the world. Zbyszek _______________________________________________ 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
