On Wed, Nov 29, 2017 at 10:16 AM, Prarit Bhargava <prarit@xxxxxxxxxx> 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. What does that have to do with bugs? Nothing. This is Fedora. You file a single bug, you point out the need to update two SRPMs with it. And that's IF you file a bug at all :) Let's not confuse the need to coordinate with bug reporting. Also, your example seems somewhat contrived. If you patch the driver but don't patch the tool, what happens? Likely not much, otherwise people would report broken tools all the time, right? >>> 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. OK. I'm not sure we've seen that in Fedora in... forever. It would be interesting to understand why there is the difference. josh _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
