On Tue, Jan 5, 2021 at 8:34 AM Colin Walters <walters@xxxxxxxxxx> wrote: > > > > On Mon, Jan 4, 2021, at 6:29 PM, Matthew Miller wrote: > > > > I also remember when this was a killer feature for Fedora, and without any > > real way of judging use and demand, I'm hesitant to kill it off. But that's > > definitely plan B. We can point people who are in low-bandwidth situations > > at Silverblue, CoreOS, and Kinoite as the preferred approach. > > Please don't use phrasing like this that implies e.g. CoreOS is distinct from "Fedora". > But as of right now, it *is*. Perhaps that will change if FCOS realigns with Fedora as part of being promoted to Edition status, but right now, it's different enough content-wise that it's less like Fedora than most of us would want it to be. > A much technically clearer way to say this would be "traditional dnf Fedora" versus rpm-ostree. > > But even then it's not fully distinct because rpm-ostree also links to libdnf and whenever you use package layering, it's all the same RPM tools on the wire. Though...ah right, the deltarpm implementation lives in the dnf Python code, not the libdnf library, so rpm-ostree doesn't do that. > > Second - and this should be emphasized - a common case at least on Silverblue is that you run dnf inside a toolbox-style container (or more than one!). So all bandwidth improvements apply there too. In other words this (implict) contrast between the two is false because in both cases there are hybrids. > > 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. 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ 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
