[Rpm-ecosystem] Some points about zchunk

[Jonathan Dieter]

On Thu, 2018-09-27 at 14:17 -0400, Neal Gompa wrote:
> On Thu, Sep 27, 2018 at 1:49 PM Jonathan Dieter <jdieter at gmail.com> wrote:
> > Apologies that it's taken so long for me to follow up on this.  So,
> > I've been working on getting librepo and libdnf up-to-date with this
> > change and it's far more difficult than you would expect.  Currently
> > the process is something like this:
> > 
> > ✔ libdnf requests primary
> > ✔ librepo cleverly changes primary to primary_zck if primary_zck exists
> > ✔ librepo downloads primary_zck
> > ✔ libdnf gets path of primary from librepo
> > ✔ libdnf passes primary path to libsolv
> > ✘ libsolv can't open primary path, because we downloaded primary_zck
> > 
> > I think the way forward is to make libdnf more aware of zchunk with the
> > following (simpler) flow:
> > 
> > ✔ libdnf requests primary_zck.  If that fails, it requests primary
> > ✔ librepo downloads primary_zck
> > ✔ libdnf gets path of primary_zck from librepo
> > ✔ libdnf passes primary_zck path to libsolv
> > ✔ libsolv opens primary_zck path
> > 
> > There are three things that I want to verify before I move forward with
> > this:
> >    1. dnf is now using libdnf, so I'm not going to have to repeat the code
> >       twice, right?
> >    2. Are the librepo consumers happy with me moving some logic to libdnf?
> >       Is there anybody who's losing zchunk support with this move?
> >    3. Is there a better way to do this?
> > 
> 
> The problem if librepo can't do it is that pure-librepo consumers are
> probably going to have issues. The main upcoming pure-librepo consumer
> is Koji to replace its yum.repoMDObject stuff and other repomd centric
> actions using the YUM API.

If this is the case, maybe we should keep it in pure librepo.  It means
doing some fancy footwork between step 2 and step 4 in the current
example, and it means that we're basically lying to our clients,
telling them that they're getting foo when they're really getting
foo_zck, but I don't think that matters as long as we're consistent.

> DNF is now using libdnf, so you shouldn't need to repeat it twice.
> 
> But that said, the path you describe makes sense.

So should I go with the first flow which abstracts zchunk away from
librepo clients or the second flow which is a bit less convoluted, but
requires librepo clients to understand zchunk?

Jonathan