On Tue, Nov 28, 2017 at 5:03 PM, Laura Abbott <labbott(a)redhat.com> wrote:
Like all good bits of software, the kernel.spec has grown over time.
Part of this growth has come from building more of the userspace
tools that live under the tools directory of the kernel. I've been
experimenting with moving these to a separate spec file.
Advantages:
- Less stuff in the kernel.spec file (~300 line deletion)
- Fewer build deps for things like perf
- People building the kernel only get the kernel
- Issues with userspace tools don't impact the kernel
- Can likely drop most of the debuginfo regex nightmare for the userspace
packages
Disadvantages:
- Would need to manually keep in sync on some cadence. This is mostly
an issue for rawhide. Could we actually get away with only re-building
on each new kernel version or do we need to resync on each -rc?
- Would probably need to rework how tools are tied to kernel versions at
the package level
- Others added here
I've experimented with something at
https://pagure.io/kernel-tools-pkggit
which is mostly a copy/paste of parts of the kernel.spec file. I'm
mostly looking for general feedback about if this a good idea but
I'm also interested in specific feedback if you have it.
If you define a specific cadence for updating, I think you can drop a
LOT of the vanilla dir and pre-release macro junk from the
kernel-tools.spec. That stuff is optimized for %prep time on a large
tree done multiple times a day, using hardlinks and all kinds of other
stuff to keep from having to expand tarballs a lot. I don't think it
makes sense to keep that structure in something we'd be looking at
building once a release or even once a week.
I'd suggest once per official RC is enough for rawhide. You shouldn't
need to deal with git snapshots and building the tools during the
merge window is a wash. Realistically, after the tools are merged
it's rare they get much in the way of updates between -rc2 and the
final release, but building once per RC would be good to start with.
Are you looking for maintainers of this package? I know I've
volunteered in the past, and I'm happy to maintain it if nobody else
wants it.
josh