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! _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
