4:03 p.m.
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
8:16 p.m.
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
8:58 a.m.
On 11/28/2017 09:16 PM, Josh Boyer wrote:
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
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?
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).
P.
9:07 a.m.
On Wed, Nov 29, 2017 at 9:58 AM, Prarit Bhargava <prarit(a)redhat.com> wrote:
On 11/28/2017 09:16 PM, Josh Boyer wrote:
> 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
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?
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...
josh
9:16 a.m.
On 11/29/2017 10:07 AM, Josh Boyer wrote:
On Wed, Nov 29, 2017 at 9:58 AM, Prarit Bhargava
<prarit(a)redhat.com> wrote:
> On 11/28/2017 09:16 PM, Josh Boyer wrote:
>> 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
>
> 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.
> 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.
P.
> josh
> _______________________________________________
> kernel mailing list -- kernel(a)lists.fedoraproject.org
> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>
9:24 a.m.
On Wed, Nov 29, 2017 at 10:16 AM, Prarit Bhargava <prarit(a)redhat.com> wrote:
On 11/29/2017 10:07 AM, Josh Boyer wrote:
> On Wed, Nov 29, 2017 at 9:58 AM, Prarit Bhargava <prarit(a)redhat.com> wrote:
>> On 11/28/2017 09:16 PM, Josh Boyer wrote:
>>> 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
>>
>> 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
11:30 a.m.
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(a)redhat.com> wrote:
>> On 11/28/2017 09:16 PM, Josh Boyer wrote:
>>> 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
>>
>> 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(a)lists.fedoraproject.org
> To unsubscribe send an email to kernel-leave(a)lists.fedoraproject.org
>
11:31 a.m.
On 11/28/2017 06:16 PM, Josh Boyer wrote:
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
I was figuring the kernel team would continue to maintain it but
I would never object to someone else dealing with it.
Thanks,
Laura
12:33 p.m.
On Tue, Nov 28, 2017 at 02:03:16PM -0800, 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.
Hi Laura,
I read the feedback from people about the multiple bzs and keeping things in
sync. This is similar to userspace utilities and I thought a Requires line
in either the kernel or utilities file would help with it.
I am more curious about the source. Does that mean you have similar source
trees but under two different dist-git packages?
Cheers,
Don
1:28 p.m.
On 11/29/2017 10:33 AM, Don Zickus wrote:
On Tue, Nov 28, 2017 at 02:03:16PM -0800, 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.
Hi Laura,
I read the feedback from people about the multiple bzs and keeping things in
sync. This is similar to userspace utilities and I thought a Requires line
in either the kernel or utilities file would help with it.
Yes, agreed. There are already some of those scattered throughout the
kernel.spec. I'd want to make sure there was some sort of coherent
strategy for adding them.
I am more curious about the source. Does that mean you have similar
source
trees but under two different dist-git packages?
Correct.
Cheers,
Don
Thanks,
Laura
2:50 p.m.
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.
Someone also mentioned the hyperv-daemons existing as a separate
spec file. I'd be okay with moving that into kernel-tools for
easier management as well.
I'll post the link to the bugzilla package review when that
happens.
Thanks,
Laura
4:13 p.m.
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(a)redhat.com
6:35 p.m.
On 12/05/2017 12: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.
Someone also mentioned the hyperv-daemons existing as a separate
spec file. I'd be okay with moving that into kernel-tools for
easier management as well.
I'll post the link to the bugzilla package review when that
happens.
Thanks,
Laura
Review is at https://bugzilla.redhat.com/show_bug.cgi?id=1523909
Thanks,
Laura
5:39 p.m.
On 12/08/2017 04:35 PM, Laura Abbott wrote:
On 12/05/2017 12: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.
>
> Someone also mentioned the hyperv-daemons existing as a separate
> spec file. I'd be okay with moving that into kernel-tools for
> easier management as well.
>
> I'll post the link to the bugzilla package review when that
> happens.
>
> Thanks,
> Laura
Review is at https://bugzilla.redhat.com/show_bug.cgi?id=1523909
Thanks,
Laura
The review was approved so I started the request for the new
repo https://pagure.io/releng/fedora-scm-requests/issue/3728
Thanks,
Laura
4:33 p.m.
On 01/02/2018 03:39 PM, Laura Abbott wrote:
On 12/08/2017 04:35 PM, Laura Abbott wrote:
> On 12/05/2017 12: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.
>>
>> Someone also mentioned the hyperv-daemons existing as a separate
>> spec file. I'd be okay with moving that into kernel-tools for
>> easier management as well.
>>
>> I'll post the link to the bugzilla package review when that
>> happens.
>>
>> Thanks,
>> Laura
>
> Review is at https://bugzilla.redhat.com/show_bug.cgi?id=1523909
>
> Thanks,
> Laura
The review was approved so I started the request for the new
repo https://pagure.io/releng/fedora-scm-requests/issue/3728
Thanks,
Laura
The tools are now removed from kernel.spec so going forward
on rawhide you must make changes to the kernel-tools package.
I did the initial import but have not yet kicked off the
build. I will do so after -rc7 on Monday.
Thanks,
Laura
2302
days inactive
2340
days old
kernel@lists.fedoraproject.org
14 comments
5 participants
participants (5)
-
Don Zickus -
Jarod Wilson -
Josh Boyer -
Laura Abbott -
Prarit Bhargava