rpm-ostree/tests/composedata/fedora-atomic-host-oirpm.spec

# The canonical version of this is in https://pagure.io/fedora-atomic
# Suppress most build root processing we are just carrying
# binary data.
%global __os_install_post /usr/lib/rpm/brp-compress %{nil}
Name: fedora-atomic-host
Version:	%{ostree_version}
Release:	1%{?dist}
Summary:	Image (rpm-ostree jigdo) for Fedora Atomic Host
License:	MIT
#@@@rpmostree_jigdo_meta@@@

%description
%{summary}

%prep

%build

%install
mkdir -p %{buildroot}%{_prefix}/lib/ostree-jigdo/%{name}
for x in *; do mv ${x} %{buildroot}%{_prefix}/lib/ostree-jigdo/%{name}; done

%files
%{_prefix}/lib/ostree-jigdo/%{name}
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-11-09 22:54:33 +03:00			`# The canonical version of this is in https://pagure.io/fedora-atomic`
			`# Suppress most build root processing we are just carrying`
			`# binary data.`
			`%global __os_install_post /usr/lib/rpm/brp-compress %{nil}`
			`Name: fedora-atomic-host`
			`Version: %{ostree_version}`
			`Release: 1%{?dist}`
			`Summary: Image (rpm-ostree jigdo) for Fedora Atomic Host`
			`License: MIT`
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-08 22:21:19 +03:00			`#@@@rpmostree_jigdo_meta@@@`
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-11-09 22:54:33 +03:00
			`%description`
			`%{summary}`

			`%prep`

			`%build`

			`%install`
			`mkdir -p %{buildroot}%{_prefix}/lib/ostree-jigdo/%{name}`
			`for x in *; do mv ${x} %{buildroot}%{_prefix}/lib/ostree-jigdo/%{name}; done`

			`%files`
			`%{_prefix}/lib/ostree-jigdo/%{name}`