On Tue, Sep 15, 2015, at 11:03 AM, Brendan Conoboy wrote: > We talked about a related question at flock: Should packages built as > COPRs be allowed into low level rings? The answer from RCM was no, > due to trust and stability issues. I think we're assuming ring 0 is > RPMs because we don't have a second package format that we deeply > understand and think is suitable. "We're building self-hosted binary RPMs from spec files because that's what we know" is very much a path to (at best) incremental improvement. That's not necessarily bad - the current model has its successes, but if we're taking this opportunity to really think about how we do what we do, I certainly think it's worth looking at the advantages and disadvantages of more radical changes. Sometimes, systems reach a "local maximum", where minor change in any direction actually makes things worse. You have to seek much larger change to find a different (ideally higher) local maximum. And concretely comparing with OpenEmbedded, it has a separation between build rules and delivery formats. It can generate debs or rpms, and I have some work on direct OpenEmbedded -> OSTree. (One could also do today OpenEmbedded -> rpms -> rpm-ostree -> ostree, or OpenEmbedded -> rpms -> docker build). > It's certainly an argument for ring 0 being the minimal install ;-) > How do you deliver updates? That depends on the product. For Project Atomic, I could certainly imagine having the Atomic Host portion come from something like OpenEmbedded (ideally with a more continuous delivery process on top for the key components I've prototyped elsewhere). The Docker base image is a lot trickier, as a lot of the ecosystem taps binary packages. That said though, we could certainly continue to provide binary RPMs, or alternatively, a common set of recipes that downstream consumers can use to build their own. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
