Re: RFC: Moving kernel-tools out of kernel.spec

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux