On Thu, Oct 16, 2014, at 11:29 PM, David Gay wrote:
Hi --
At this point, I thought I'd send out an email with my current
understanding of the processes we need to add to the releng scripts for
ostree, as well as some questions regarding these compose scripts,
specifically:
Awesome, thanks for sending this out!
It seems to me that we should add in the bulk of the ostree processes
after the compose process completes, but before the rsync. In
buildbranched, this is at line 180. In buildrawhide, this is at line 172.
This would be where we'd init an ostree repo somewhere like
/srv/ostree/repo, use our treefile to run the compose (which captures
RPMs to build the tree), and then generate a summary of the repo with
`ostree summary -u`.
Right. An interesting question around this though is how much history
to retain. I'd hope for at least two commits. That way users are less
likely to see objects vanish underneath them they try to upgrade while a
rsync runs for a mirror.
For our purposes, the summary file resulting from
this process would serve a comparable purpose as the repomd.xml file we
use for our "standard" builds.
Yep, that's the intention.
1. n00b question: I'm not sure how what needs to go *in* an image
is
decided. In order to run the ostree compose, we need to generate a
treefile that contains -- among other things -- a list of RPMs that need
to be installed. What's the best way to get content for that list?
This is in
https://git.fedorahosted.org/cgit/fedora-atomic.git
2. The treefile also needs a branch name for the content. Any input
on
the naming scheme?
At the moment the branch name is specified in the treefile, although it
doesn't have to be. If rel-eng has input on what they want for the
branch
names I'd be happy to discuss. The current one is just a convention.
3. The treefile can also take a number of optional values. I'm
not sure
if any are needed for this process, but they are listed here:
https://github.com/projectatomic/rpm-ostree/blob/master/doc/treefile.md
Perhaps `gpg_key`, `boot_location`, and/or `units`?
I'd like to maintain the content definition upstream - signing for
Fedora
at the moment is going to have to be on the summary file. Let's get
to that later - the HTTPS protection on the metalink is going to be good
enough.
Thanks again for looking at this!