[Rpm-ecosystem] Some points about zchunk

[Neal Gompa]

On Thu, Sep 27, 2018 at 2:45 PM Jonathan Dieter <jdieter at gmail.com> wrote:
>
> 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?
>

The second flow.


-- 
真実はいつも一つ！/ Always, there's only one truth!