[Rpm-ecosystem] Fwd: Proposing a new way to deliver Atomic systems: rpm-ostree jigdo ♲📦

Colin Walters walters at verbum.org
Wed Dec 6 19:51:08 UTC 2017


Forwarding this here since it's quite relevant; I also think it's quite
*interesting* for people interested in package/image systems.

One consequence is I'll probably start doing some more patches
for librepo.  Related to that, a bigger issue looms:
https://github.com/projectatomic/rpm-ostree/issues/1127

Anyways just sending this along since I think it'll be interesting
for this audience; I'll bring up the repodata issue when I have
time to circle back to that.

----- Original message -----
From: Colin Walters <walters at verbum.org>
To: "atomic-devel" <atomic-devel at projectatomic.io>
Subject: Proposing a new way to deliver Atomic systems: rpm-ostree jigdo ♲📦
Date: Wed, 06 Dec 2017 13:11:11 -0500

I've been working on Project Atomic for several years now; first post:

https://lists.projectatomic.io/projectatomic-archives/atomic-devel/2014-April/msg00000.html

(And the rpm-ostree/ostree projects predate that; rpm-ostree's "gitbirthday" is
 coming up at Sat Dec 21 19:41:30 2013 -0500)

This entire time we've dealt with 3 binary formats: RPM, Docker (now OCI) and OSTree.
The tension is...powerful.   It leaks through into how people manage systems; issues
like "how do I mirror this content" are serious blockers for lots of organizations
that don't want their systems Intenet connected.  Obviously I've thought about this a lot,
and I now have a concrete proposal now to try to get that closer to two formats.

Basically, we're reviving an old idea for the modern age of images; I'm calling
it "rpm-ostree jigdo ♲📦" (emoji are for "recycle package"):

https://github.com/projectatomic/rpm-ostree/issues/1081

I won't repaste it all here - just the header, which follows.  Feel free though
to follow up here - email works well for this sort of thing.  The high level
status is: things are moving quickly, and the next step is to start fleshing out
the client side.  So it's at the point where I want concrete feedback.

Upstream issue follows below:

Fetching content via both ostree and libdnf ends up mixing the tradeoffs of both, requires release engineering to manage both, and makes it harder to mirror content. Not to mention the fact that there's the whole OCI/Docker thing which also works in a completely different way, and admins need to manage/mirror that too.

Now while the "obvious" thing would be to try to align with OCI in some way, the complete lack of wire deltas there is very problematic for uses outside of server clusters, and given that we already have lots of extensive linkage to RPM via libdnf, it makes the most sense to move that direction.

Hence, let's experiment with doing ostree-in-RPM ... [ read more at https://github.com/projectatomic/rpm-ostree/issues/1081 ]



More information about the Rpm-ecosystem mailing list