On Tue, 2021-01-05 at 18:18 +0100, Daniel Mach wrote: > Dne 24. 12. 20 v 22:54 Matthew Almond via devel napsal(a): > > Depends on how it got there, and what you asked for. Here's some > > examples: > > > > 1. cp foo.rpm /var/cache/dnf/<repo>/Packages/ && dnf install foo > > ...will fail the librepo full file check, and it'll be re- > > downloaded. > > 2. dnf install /root/foo.rpm || rpm -i /root/foo.rpm > > (not actually tested) will likely fail with CPIO/payload error > > > > Note that tools like rpm2cpio and rpm2archive will also fail on > > transcoded rpms. I have an open task to make the dnf plugin not > > transcode with 'yumdownloader' or 'dnf download' (plugin) as those > > are > > reasonable command to run. I will look at making error messages > > better > > and/or making some of these use cases work. > > > > This concerns us (speaking for RPM and DNF people) a little bit. > If the transcoded RPM cannot be used as a regular RPM, it probably > should have a different identity, for example a different suffix > than > .rpm. RPM and DNF are designed for generic use cases. I see these > transcoded packages as a "cache" tailored for btrfs based systems > only. > It would be probably good to draw a border between them. > > If I understand it correctly, the transcoding happens on each host. > Have > you considered transcoding all RPMs in a repo on server instead? Or > would that be inefficient and increase network traffic too much? > The transcoded RPM is a valid RPM for the rpm program and most use cases. It's got all the original headers, so querying it (-qp) works perfectly, and it's still signed, and it's only produced in concert with dnf/librepo which validates that the file downloaded is the one described in the repo. Notably it doesn't work with rpm2cpio and rpm2archive (and yes, I'd like to have a better story there). You typically get these through 'dnf download'. When I implemented the plugin for yum, I was able to avoid transcoding, but on dnf it's not implemented yet. Signature *verification* partially works. Everything to do with signatures on just the header works (and the header describes the payload digest). There is one specific area which needs fixed: regular RPMs are read, digested, and signature verified before decompression. We need to guard against malicious compressed payloads that either perform a DoS on space/time, or worse (but more difficult) could exploit a bug in a decompression library. I am actively working on this. The bottom line is that in every place you'd expect to see an rpm, and use it later, you have exactly the same number of things in the same place. If you want to reflink clone the dnf cache into a container - it'll work (really well). If you want to clean up the cache in some selective way. The interface for the cache remains the same. On server side: no this doesn't make sense: you'd save on decompressing, but you'd use 2x the bandwidth and space on server side. You'll also need to keep the original rpms for clients that don't or can't use reflinking, so it's more like 2.5x the space, which I think is unreasonable. I do think there's some room in the future to think and talk about how repos could be changed to take better advantage of this. I got some feedback on RPM PR ( https://github.com/rpm-software-management/rpm/pull/1470#issuecomment-754025728 ) which is somewhere along the lines of what I was already thinking. That said, I'm aware that I'm being ambitious with this change request, and I'm focused on trying to integrate things that have been written/exist and can be demonstrated first. Hope these explanations help! Thanks for the feedback :) Matthew. _______________________________________________ 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
