On Mon, Jul 2, 2018 at 5:04 PM Gerald B. Cox <gbcox@bzb.us> wrote:


On Mon, Jul 2, 2018 at 8:06 AM, Igor Gnatenko <ignatenkobrain@fedoraproject.org> wrote:
On Mon, Jul 2, 2018, 15:54 Gerald B. Cox <gbcox@bzb.us> wrote:

It appears to be a good idea, but when going through the readme, I found this:

Please note that, while the code is pretty reliable and the file format shouldn't see any further changes, the API is still not fixed. Please do not use zchunk for any mission-critical systems yet.

I would consider DNF to be a mission critical system.  Shouldn't we wait until zchunk is deemed
ready?  I don't understand how it is OK to use this for DNF, but it isn't OK for
"any mission-critical systems".

I would say that DNF must do proper fallback in which case if zchunk fails, DNF falls back to downloading full metadata. However, DNF does that do any out-of-process metadata handling which might crash it entirely (but I think we can fix such issues quickly).
--
I believe you're missing my point here... DNF should always do proper fallback - that wasn't the concern.  The concern is why we are implementing a change to DNF using software that
by it's own admission should not be used for mission critical systems? 

Ah, you mean this. So the problem here is that there is no alternative to this here. There is casync, but it is not designed for this type of usage. Zchunk is good, but it's really dead.
--

-Igor Gnatenko