On Thu, Jul 12, 2018 at 3:27 PM Jonathan Dieter <jdie...@gmail.com> wrote: > > On Wed, 2018-07-11 at 07:55 -0400, Neal Gompa wrote: > > On Wed, Jul 11, 2018 at 7:30 AM Michael Schroeder <m...@suse.de> wrote: > > > > > > On Wed, Jul 11, 2018 at 12:23:47PM +0100, Jonathan Dieter wrote: > > > > That's something I didn't think of, and you're absolutely right. > > > > > > > > So, to summarize, we'll leave the gzip entry as "primary", so legacy > > > > systems will still download without any problems, and create a new > > > > "primary@zchunk" that librepo will automagically download if zchunk is > > > > supported? > > > > > > I think there should be some librepo option to enable this. Be it > > > something boolean or a fancy string list that can be used for > > > some future compression method. > > > > > > But I'm just one person. Can someone else on this list please speak > > > up and tell us if we want to do something stupid or not? Maybe the > > > librepo maintainer? Or the libdnf maintainer? Anybody? > > > > > > > While I agree that we should have an attribute that declares the > > compression format for fetching, I wonder how legacy clients would > > handle it? There must be a reason why we haven't done it so far after > > going from gzip to bzip2 to lzma to xz? > > > > It's not unprecedented for there to be stuff like this (we handle the > > sqlite data variant with <foo>_db). We could, for consistency, do > > "<foo>_zckxml" and have librepo fetch that when it's available. > > I'd go with <foo>_zck since <foo> is, by default, xml, but, other than > that, I think what you (and Michael) are suggesting makes sense. > > Michael, I agree that there should be some way to manually enable > zchunk (with a method that will work with future algorithms) in > librepo. > > I don't mind writing the code, but I'd like to hear some consensus on > the method and element name.
I'm okay with this, but does this mean we could also have (cheaply) zck of arbitrary xml files appended using tools like modifyrepo_c, then? -- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ Rpm-ecosystem mailing list Rpm-ecosystem@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-ecosystem