On Mon, 2018-11-19 at 20:16 +0100, Jan Pokorný wrote: > On 19/11/18 13:13 +0100, Nicolas Mailhot wrote: > > Le 2018-11-19 12:28, Martin Kolman a écrit : > > > > > Many people might think RAM would not be an issue in 2018, but in > > > practice there are > > > and likely always will be memory constrained installation targets, > > > such as massive deployments > > > of "small" VMs or the IoT use cases mentioned above. > > > > Sure, that’s the artificial small vm case > > > > The average old/limited hardware is limited in memory, cpu and storage. > > Therefore if you have one factor to sacrifice it's cpu time because you can > > always let the CPU run a little longer, but a limited system won't magically > > grow more memory or more storage. > > > > Storage would not be such a problem is dnf was smart enough to auto > > partition big upgrades in lots of small partial upgrades, before downloading > > gigs of data that do not fit on disk. > > https://bugzilla.redhat.com/show_bug.cgi?id=1609824 > > Also, not familiar with zchunk way of doing things, but couldn't > rpm-integrity-verified installed files be mapped back to "chunks" > to further aleviate space concerns for the machine receiving > updates in some cases? That's an interesting thought. I was picturing using the zchunk library in the dnf download stage to build a local rpm from the verified locally installed files and the downloaded changed chunks, but, if I understand your suggestions correctly, you're saying we could just download the changed chunks and have RPM automatically get the rpm-integrity verified chunks during the *install* stage. The advantage of this method is that you don't need to store the local data twice, but the danger is that the local files get changed elsewhere during the install process. It's an interesting thought, though, and I wonder if there's a way we could work around that danger? Jonathan
Attachment:
signature.asc
Description: This is a digitally signed message part
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
