On Wed, 2005-07-06 at 18:16 +0300, Ville Skyttä wrote:
- in the beginning, we have only kernel X
- rebuild a kernel-module-foo package for it, results:
- k-m-foo-1.0-1.src.rpm
- k-m-foo-1.0-1.X...rpm (all smp, xen0 etc variants and archs)
- the above get pushed to the repository
- then, kernel Y is released, rebuild k-m-foo (which has had no changes in the meantime) for it, results:
- k-m-foo-1.0-1.src.rpm
- k-m-foo-1.0-1.Y...rpm (all smp, xen0 etc variants and archs)
Do we discard the new k-m-foo-1.0-1.src.rpm or overwrite the one which is already in the repository?
I vote we discard the new one.
Or do we solve this with a policy (assuming the process you described above would be implemented): "always bump the release of the "main" package of a module package before building it for a new kernel"? That'd result in only one srpm per module package per released kernel "family".
It would also result in unnecessary package upgrades.
Also, if possible, it would be awesome if the buildsystem could automatically do a build when a new kernel goes into FC (for that kernel only). Barring that, it would be nice if there was some way for kernel-module-* maintainers to be notified of the new kernel update in advance.
Sure. But I'm becoming worried about this discussion already placing requirements on the build system, which will delay our ability to ship any module packages even further. We could start with something much simpler; several suggestions have already been outlined in this thread. The day "make build" would allow specifying the arch, we could start building and shipping the packages, and could improve the process incrementally.
The build system has other issues. Right now, I don't think it can deal with ExclusiveArch correctly. If it did, then we could just have "make build" parse ExclusiveArch for kernel-module packages, and build for all those arches. I've CC'd seth and dan to see what they say.
~spot