Am Donnerstag, den 12.01.2006, 11:56 -0500 schrieb Dan Williams: > So DavidZ and I were talking about this, and the matrix of different > modules for just one SRPM here gets huge. We have the following issues: > > 1) UP, SMP, hugemen, XEN We have no hugemem currently, but xen-guest and xen-hypervisor. > 2) i586, i686, x86_64, em64t, ppc32, ppc64, ia64 No extras for ia64 (yet) and em64t has no special kernel/is mostly x86_64 anyway. But you forgot ppc64iseries. > 3) How many past kernels to rebuild for See below: > Even with just these 3, we get at _least_ 30 different kernel module > RPMs (3 "flavors", minimum of 5 arches, 2 past kernels). That's a huge > number. I count 12 kernels (without past ones) that are of interest for Fedora Extras: 1 | i586 -- UP 4 | i686 -- UP, SMP, xen-xen-guest, xen-hypervisor 3 | x86_64 -- SMP, xen-xen-guest, xen-hypervisor (soon, hopefully) 2 | ppc -- UP, SMP (no xen yet afaik) 1 | ppc64 -- SMP 1 | ppc64iseries -- SMP === 12 resulting RPMs build on 6 targets with one SRPM per target ^^^ > Questions: > > Is this really what we want? I don't think we get below those 12. Maybe 11 if we ignore ppc64iseries ;-) > How do we deal with the explosion of permutations of kernel modules? Good question. > Resources in the buildsystem aren't infinite, how many jobs/rpmbuilds > should we actually kick off? If it's only those six and no past kernel it shouldn't block the buildsystems for too long AFAICS and IMHO. > We can't possibly rebuild modules for every previously released kernel.[...] Agreed. My vote: Only build for the newest one. <insert complains from Ralf Corsepius here>; Answer: Ralf, let's build only for the newest one in the beginning. If that doesn't work we can still come back to this point and discuss it anew. > This is all independent of the actual specfile mechanisms and mechanics > of rebuilding the modules. As long as we don't go back to the old scheme where one SRPM did build one RPM. > This is simply a question of how many > factors do we care about here. [...] Did I miss anything? CU thl -- Thorsten Leemhuis <fedora@xxxxxxxxxxxxx> -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
