On Mon, Jul 2, 2018 at 5:04 PM Gerald B. Cox <gb...@bzb.us> wrote: > > > On Mon, Jul 2, 2018 at 8:06 AM, Igor Gnatenko < > ignatenkobr...@fedoraproject.org> wrote: > >> On Mon, Jul 2, 2018, 15:54 Gerald B. Cox <gb...@bzb.us> wrote: >> >>> https://fedoraproject.org/wiki/Changes/Zchunk_Metadata >>> >>> 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
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/ITGRRPKWPU5PM6P7JI27R5OWAQ7IMEWM/
