On Tue, Jan 2, 2018 at 11:56 PM, Paul Bolle <pebolle@xxxxxxxxxx> wrote: > On Tue, 2018-01-02 at 17:27 -0500, Josh Boyer wrote: >> If you're talking about local builds, it isn't tricky at all. Someone >> would just need to adjust the kernel.spec to do it and/or write steps >> to have your local git tree in a state that the existing spec could >> use. You could even use the existing exploded tree because the >> configs are all there as well. > > If the end result is something that closely tracks kernel.git that sounds > rather nice. (Even better would be a tree that kernel.git itself uses, but now > I'm getting carried away a bit.) > > I should try to create something that somehow-sort-of does what I want first, > I guess. Bother. I'd rather just snap my fingers! > >> If you're talking about building Fedora kernels officially from an >> exploded tree, there are two tricky issues. >> >> 1) You still have to at least create a tarball and upload that because >> koji can't build from exploded source. That means you're uploading a >> massive tarball every day and it's terrible. > > But koji isn't carved in stone, is it? No, but in the current status quo it can't pull from random sources (Fedora config, not koji in general), this is an explicit decision for audit and related requirements so what goes into a build can be reproduced and reviewed. >> 2) The tracking of patches Fedora carries on top of upstream results >> in forced rebases. You see that with the existing exploded tree we >> have on kernel.org, but that literally is just an exploded tree of >> builds. It's not really great for development. For development >> purposes, the forced rebases makes it really crappy to work with. The >> alternative is a ton of merges, which would be possible but alas is >> not great either. > > Sorry, I'm only consuming the kernel.git efforts, so it's hard for me to truly > understand the effort involved. > > Thanks for taking the time to respond to my semi-cooked ideas! > > > Paul Bolle > _______________________________________________ > kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
