On Mon, Apr 16, 2018 at 8:47 AM, Jonathan Dieter <jdie...@gmail.com> wrote:
> It's been a number of weeks since my last update, so I thought I'd let
> everyone know where things are at.
>
> I've spent most of these last few weeks reworking zchunk's API to make
> it easier to use and more in line with what other compression tools
> use, and I'm mostly happy with it now.  Writing a simple zchunk file
> can be done in a few lines of code, while reading one is also simple.
>
> I've also added zchunk support to createrepo_c (see
> https://github.com/jdieter/createrepo_c), but I haven't yet created a
> pull request because I'm not sure if my current implementation is the
> best method.  My current effort only zchunks primary.xml, filelists.xml
> and other.xml and doesn't change the sort order.
>

Fedora COPR, Open Build Service, Mageia, and openSUSE also append
AppStream data to repodata to ship AppStream information. Is there a
way we can incorporate this into zck rpm-md? There's been an issue for
a while to support generating the AppStream metadata as part of the
createrepo_c run using the libappstream-builder library[1], which may
lend itself to doing this properly.

[1]: https://github.com/rpm-software-management/createrepo_c/issues/75

> The one area of zchunk that still needs some API work is the download
> and chunk merge API, and I'm planning to clean that up as I add zchunk
> support to librepo.
>
> Some things I'd still like to add to zchunk:
>  * A python API
>  * GPG signatures in addition to (possibly replacing) overall data
>    checksum

I'd rather not lose checksums, but GPG signatures would definitely be
necessary, as openSUSE needs them, and we'd definitely like to have
them in Fedora[2], COPR[3], and Mageia[4].

[2]: https://pagure.io/releng/issue/133
[3]: https://bugzilla.redhat.com/show_bug.cgi?id=1373331
[4]: https://bugs.mageia.org/show_bug.cgi?id=19432

>  * An expiry field? (I'm obviously thinking about signed repodata here)

Do we need an expiry field if we properly processed the key
revocation/expiration in librepo? My understanding is that current
hiccup with it is that we don't, and that the GPG keyring used in
librepo is independent of the RPM keyring (which it shouldn't be).


-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
infrastructure mailing list -- infrastructure@lists.fedoraproject.org
To unsubscribe send an email to infrastructure-le...@lists.fedoraproject.org

Reply via email to