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 > > 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 _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx
