On 2017-12-05 3:50 PM, Laura Abbott wrote:
On 11/28/2017 02:03 PM, Laura Abbott 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.
Thanks,
Laura
Giving this some thought, this is still a proposal I want to push forward.
The biggest feedback I heard about this was
- Synchronization
- Applying patches across the tree
For the synchronization issue, Don Zickus pointed out that we can
use Requires as needed. We have this already on some of the kernel
packages and can add others as needed. It's also very easy to
ask users to update to a newer package if something gets out of
sync.
I don't have a great solution for cases where patches are applied
across the tree and touch both the kernel and userspace tools.
Such patches are bad style IMHO since the userspace tools are
supposed to be userspace programs. For Fedora's usage, such
patches would probably exist separately for such a short period
of time that I don't think it would be difficult to manage.
Fedora gets very few patches for the tools anyway.
We used to get patches that touched both firmware and kernel code before
linux-firmware was shipped separately. It's been handled just fine for
the most part with two patches and Requires: in the kernel spec, once
people were properly trained, though it's a slightly different case with
linux-firmware actually being a separate source tree upstream now, while
the tools are still in the kernel tree. I'd actually be curious to know
why they aren't simply split out into their own tree upstream, but
that's a tangential issue.
I'd agree with Josh's idea to build tools every rc during development,
then at release, and at a -stable release iff there's a patch that
touches tools that we care about.
--
Jarod Wilson
jarod@xxxxxxxxxx
_______________________________________________
kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
