On Thu, 2018-09-27 at 14:17 -0400, Neal Gompa wrote: > On Thu, Sep 27, 2018 at 1:49 PM Jonathan Dieter <jdie...@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 _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem
