rpm-ostree

keremet/rpm-ostree

Fork 0

Commit Graph

Author	SHA1	Message	Date
Colin Walters	ca2a651619	commit2jigdo: Synthesize Requires: for jigdo set Having the "jigdo set" in repodata makes it so we can parallel download the jigdo RPM with the set. However for now, I kept the jigdo set in the jigdoRPM, since that way it'll be covered by the signature. Also, this changes the way we inject metadata to use a magic comment string, since trying to pass a gigantic macro to `rpmbuild` via its argv didn't work out so well (it looks like rpmbuild eats newlines). This approach is more robust. Closes: https://github.com/projectatomic/rpm-ostree/issues/1132 Closes: #1140 Approved by: jlebon	2017-12-12 19:31:36 +00:00
Colin Walters	c3b152f3ee	jigdo: Add Provides: rpmostree-jigdo(v1), require it on client We are going to want versioning on the jigdo RPMs, since it's highly likely things change. This is done via new magic '-D rpmostree_jigdo_meta` macro, which we can also use for other things down the line. Closes: #1135 Approved by: jlebon	2017-12-07 18:32:49 +00:00
Colin Walters	694b798c73	Introduce experimental "rpm-ostree jigdo" Tracking issue: https://github.com/projectatomic/rpm-ostree/issues/1081 To briefly recap: Let's experiment with doing ostree-in-RPM, basically the "compose" process injects additional data (SELinux labels for example) in an "ostree image" RPM, like `fedora-atomic-host-27.8-1.x86_64.rpm`. That "ostree image" RPM will contain the OSTree commit+metadata, and tell us what RPMs we need need to download. For updates, like `yum update` we only download changed RPMs, plus the new "oirpm". But SELinux labeling, depsolving, etc. are still done server side, and we still have a reliable OSTree commit checksum. This is a lot like [Jigdo](http://atterer.org/jigdo/) Here we fully demonstrate the concept working end-to-end; we use the "traditional" `compose tree` to commit a bunch of RPMs to an OSTree repo, which has a checksum, version etc. Then the new `ex commit2jigdo` generates the "oirpm". This is the "server side" operation. Next simulating the client side, `jigdo2commit` takes the OIRPM and uses it and downloads the "jigdo set" RPMs, fully regenerating bit for bit the final OSTree commit. If you want to play with this, I'd take a look at the `test-jigdo.sh`; from there you can find other useful bits like the example `fedora-atomic-host.spec` file (though the canonical copy of this will likely land in the [fedora-atomic](http://pagure.io/fedora-atomic) manifest git repo. Closes: #1103 Approved by: jlebon	2017-12-04 14:24:53 +00:00

Author

SHA1

Message

Date

Colin Walters

ca2a651619

commit2jigdo: Synthesize Requires: for jigdo set

Having the "jigdo set" in repodata makes it so we can parallel download the
jigdo RPM with the set. However for now, I kept the jigdo set in the jigdoRPM,
since that way it'll be covered by the signature.

Also, this changes the way we inject metadata to use a magic comment string,
since trying to pass a gigantic macro to `rpmbuild` via its argv didn't work out
so well (it looks like rpmbuild eats newlines). This approach is more robust.

Closes: https://github.com/projectatomic/rpm-ostree/issues/1132

Closes: #1140
Approved by: jlebon

2017-12-12 19:31:36 +00:00

Colin Walters

c3b152f3ee

jigdo: Add Provides: rpmostree-jigdo(v1), require it on client

We are going to want versioning on the jigdo RPMs, since it's
highly likely things change.

This is done via new magic '-D rpmostree_jigdo_meta` macro, which we can also
use for other things down the line.

Closes: #1135
Approved by: jlebon

2017-12-07 18:32:49 +00:00

Colin Walters

694b798c73

Introduce experimental "rpm-ostree jigdo"

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

To briefly recap: Let's experiment with doing ostree-in-RPM, basically the
"compose" process injects additional data (SELinux labels for example) in an
"ostree image" RPM, like `fedora-atomic-host-27.8-1.x86_64.rpm`. That "ostree
image" RPM will contain the OSTree commit+metadata, and tell us what RPMs we
need need to download. For updates, like `yum update` we only download changed
RPMs, plus the new "oirpm". But SELinux labeling, depsolving, etc. are still
done server side, and we still have a reliable OSTree commit checksum.

This is a lot like [Jigdo](http://atterer.org/jigdo/)

Here we fully demonstrate the concept working end-to-end; we use the
"traditional" `compose tree` to commit a bunch of RPMs to an OSTree repo, which
has a checksum, version etc. Then the new `ex commit2jigdo` generates the
"oirpm". This is the "server side" operation. Next simulating the client side,
`jigdo2commit` takes the OIRPM and uses it and downloads the "jigdo set" RPMs,
fully regenerating *bit for bit* the final OSTree commit.

If you want to play with this, I'd take a look at the `test-jigdo.sh`; from
there you can find other useful bits like the example `fedora-atomic-host.spec`
file (though the canonical copy of this will likely land in the
[fedora-atomic](http://pagure.io/fedora-atomic) manifest git repo.

Closes: #1103
Approved by: jlebon

2017-12-04 14:24:53 +00:00

3 Commits