On Mon, 2005-07-04 at 09:30 -0500, Tom 'spot' Callaway wrote:
On Sun, 2005-07-03 at 21:01 +0200, Thorsten Leemhuis wrote:
- create the debug-pkg ourself and don't rely on the internal rpm
solution.
[...]
If 1) is easy I'll vote for that.
I tried, was not that hard (if I didn't miss anything). Results are found at http://www.leemhuis.info/files/fedorarpms/MISC.fdr/kernel-module-example/ in the wiki at http://www.fedoraproject.org/wiki/Extras/KernelModuleProposal
I like this approach the best.
I like that too, but the dilemma with the same-NEVR'd source rpm persists. I'm not sure if it's a design goal or a design flaw, but the little (ha!) pedant in me says it's the latter. To clarify:
- kernel-module-foo-1.0-1.src.rpm in repo - check out the package from CVS, build for a new kernel -> get another kernel-module-foo-1.0-1.src.rpm which != the original
What to do with the new source rpm? Discarding would be ugly, and overwriting the existing srpm in the repo even uglier. Rebuilding from an existing srpm in the repo would help (or just pretending it was done, and discarding the new one :)).
Allowing the source rpm's NEVR to change between rebuilds as usual and always shipping them would not have this problem at the (negligible IMHO) cost of more disk space consumption. That approach would not need any special -debuginfo treatment either.
In this scenario, we'd just need to figure out how we'd like the CVS tags to be. Turning things upside down and explicitly specifying a default %{kver} assignment in specfiles when new kernels are released (+ the smp etc variants each separately) and allowing local rebuilders override it with a --define would solve that easily, with the added benefit that the build system wouldn't have to know about passing any special --defines to these builds. Whoever requests the builds would just have to be able to specify the target architecture(s). As an example, I've changed kernel-module-thinkpad in Extras CVS (devel) to do the above (currently for the UP build).
Mmh, maybe I should just shut up about this now :). Does the above make any sense?
The only change is that the -debuginfo package needs to Require: kernel-module-%{mainpkgname} (its not any good without it).
Note: -debuginfo packages created the usual way don't have that dependency. But that's probably because it could be hard to implement in the automagic that generates them nowadays. If such a dependency would be added, it should be fully versioned, though.
As to location, I'm very inclined to standardize on: /lib/modules/%{kver}/extra/%{mainpkgname}
Works for me.