On Tue, Jan 2, 2018 at 4:55 PM, Paul Bolle <pebolle(a)tiscali.nl> wrote:
On Tue, 2018-01-02 at 12:32 -0800, Laura Abbott wrote:
> On 01/02/2018 08:35 AM, Paul Bolle wrote:
> > A bit off topic: I suppose at the ultimate goal is to do rpmbuild from within
> > a proper git clone of the kernel repository. Ie, using a branch with
> > patches, a specfile, and whatever else we need. Perhaps further gitifying the
> > current specfile helps to reach that goal. Not sure, though.
> If you're referring to the rpmbuild in the upstream kernel tree, I don't
> think it's particularly feasible for an official distribution. We end up
> doing a lot of extra things on top of what's necessary just to package the
> kernel and modules. I do want to experiment with making the upstream rpmbuild
> more useful though.
That might be very useful, and probably is a lot of work, but that wasn't what
I was hinting at. Sorry.
We're juggling tarballs and patches to build Fedora specific kernel rpms while
all information that we need is already in the kernel git repo clone that's
already on our machines. So what I was hinting at that I would like to do
git remote add kernel-pkg fedoraproject.org/whatever
and then (in a kernel-pkg related branch) do
rpmbuild --i-want-a-pony --foo --bar kernel.spec
and end up with Fedora specific kernel rpms.
Sounds simple, so it must be a tricky problem to solve.
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 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.
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.