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

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

 



On 11/29/2017 07:16 AM, Prarit Bhargava wrote:


On 11/29/2017 10:07 AM, Josh Boyer wrote:
On Wed, Nov 29, 2017 at 9:58 AM, Prarit Bhargava <prarit@xxxxxxxxxx> wrote:
On 11/28/2017 09:16 PM, Josh Boyer wrote:
On Tue, Nov 28, 2017 at 5:03 PM, Laura Abbott <labbott@xxxxxxxxxx> 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

IIUC this means if I have a patch that touches tools/power/turbostat and
drivers/idle/intel_idle.c I now have to open up two bugzillas to track things so
that the kernel and kernel tools is synchronized?

No?  Why would you need two bugs?

For example, the kernel package is built every night.  And the kernel-tools
package is now built randomly (if it is automatically built when the kernel
package is built then there's no problem).

I apply a patch that (in my example above) patches both tools/power/turbostat
and drivers/idle/intel_idle.c I need *both* packages to be built.  If
kernel-tools and the kernel packages are out-of-sync with one another then
there's going to be a problem.


I've heard this feedback a lot and it's a case we don't see in
Fedora. We rarely get requests to add patches that touch the
userspace tools.


There are times where tools/power require changes to real kernel code and the
userspace tools.  While this is happening less frequently, it has happened in
the past and it could happen in the future.  Anyone on the virt side of things
want to comment?  ISTR having a conversation with someone about versions of
tools/hv requiring *specific* kernel versions (I'm foggy on the details).

None of the existing kernel-tools packages have any sort of Requires
on specific kernel versions.  If that is actually a problem, they
could be added but it doesn't appear to actually be an issue today...


I've hit this situation a few times with RHEL, where someone updated the kernel
rpm but not the kernel-tools rpm.  It probably happens more often at the server
level because of the tools usage.  It has never taken more than a "Please update
your kernel-tools package" to get the reporter to fix the problem.


I think this again is a RHEL vs. Fedora difference. I appreciate the feedback.

Thanks,
Laura


P.

josh
_______________________________________________
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




[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