Add deltarpm support

[ffesti]

Allow rpm to directly process delta rpms. One way would be to have a previous unpack step that places the files on disk with tsid suffixes - just as rpm does during installation. The delta rpm would then be added to the transaction with a special flag. Most operations would be done just like with a normal package. Just during the installation files would not be unpacked. Instead fsmCommit() would move the previously placed files to their final location.

This may need some extra code to remove or not even place the files that are excluded by (command line) options.

This should save a lot of diskspace during updates and also time and IO. This will probably need support from the updaters unless they can be tricked by deltarpm that they are now dealing with proper packages.

[ffesti]

The limitations of delta rpms are well known.
My idea is that instead of building the new rpm package from the delta rpm and the data on disk a separate tool would create the altered files on disk with a suffix. This would be done before the rpm transaction by the updater. If this fails the files would be cleaned up and the full package would need to be downloaded - just as if the construction of the new rpm package had failed.

The rpm part of this would just add the header from the delta rpm to the transaction. But instead of putting the files to disk from the payload it would leave the unchanged files in place and use the previously placed files for the others. So the changes needed in rpm are probably pretty small. But it would save moving all the unchanged data around which makes delta rpms very unattractive right now. Especially as network traffic has become so cheap compared with local IO.

[mlschroe]

The beauty of the current way deltarpms are handled is that it's just some funky transport mechanism to get the full rpm. (Though I agree that the payload re-compression is the weak spot.)

[ffesti]

The idea here is to not copy the unchanged files at all. So to not only save the compression but the moving around of most of the data. Sure, we would still need to read and check sum them (twice probably). Yes, this is inherently more risky than reconstructing the original package. But it is also much quicker.

[ffesti]

May be one could construct a package with only the modified (and config) files in the payload. That might only require very minimal changes on the rpm side. And updaters may not even notice...

[Conan-Kudo]

This sounds like we'd need a variant of the repackage functionality that rpm used to have a long time ago to be able to generate something that looks like an RPM to generate what's needed to apply the delta.

[ffesti]

Doesn't look like this is happing any time soon. Closing.

[Conan-Kudo]

😢