Johnny Hughes wrote: > I build those kmod RPMS from SVN and not the SPRMS (though a temporary > SRPMS is created in the process). > > Regardless ... the KERNEL VERSION that is in the SRPM name is not > relevant (as it totally depends on the KERNEL that is installed when the > SRPM is built). > > The SRPM that is posted in the CentOSPlus (or Extras) repo will build > the kmod files that are released and there is no reason to update it > unless something other than the kernel version changes. > > Example: > > xfs-kmod-0.4-1.2.6.18_8.1.1.el5.src.rpm > > The relevant part is "xfs-kmod-0.4-1" and el5. No need to publish a > dozen SRPMS that are identical in content. The who purpose of a kmod > SRPM is that it can build for multiple ARCHES and multiple VERSIONS from > the same RPM. > > As to plus and extras ... sure I can put the SRPMS in both. Changing > where the kmod files are is a relatively new thing. DRBD was all in > Extras and XFS was all in Plus ... but I changed that at user request so > that only the PLUS kenrel kmods are in plus and the regular kernel kmods > are in extras (as people did not know how to set excludes in their yum > config files to get regular kmod RPMS with plus kmod RPMS present). > > In fact, I did create hardlinks for all kmod SRPMS in extras and > centosplus. i understand all the above since i also used to recompile kmod in the same way. the only problem with the missing src.rpms is that i can't know from which source it was build and whether is there any changes in the spec file. eg in the above case i dont know xfs-kmod-0.4-1.2.6.18_8.1.1.el5.src.rpm is based on the same spec file as xfs-kmod-0.4-1.2.6.18_8.1.14.el5.src.rpm and if the spec file contians additional patches they are different or the same etc. for me a read-only svn access would be as good as the src.rpm, but afaik currently that svn is not public. -- Levente "Si vis pacem para bellum!"