On Tue, Apr 24, 2007 at 11:26:57PM -0700, Ram Pai wrote: > On Wed, 2007-04-25 at 09:13 +0700, Fajar A. Nugraha wrote: > > Ram Pai wrote: > > > Hi, > > > > > > I have this unique problem. I am planning on providing through yum > > > repositories, driver rpms for different versions of the distro kernel. > > > As and when new kernel is available and installed by the user, the > > > corresponding rpm for the driver is automatically made available in the > > > repositories. > > Although Michael's response to pass kernel version to yum is > > interesting, I believe the aproach you're looking for requires that the > > particular kernel version (or to be accurate, the kernel-devel package > > incase of RHEL) is also installed on the yum server. > > > Yes. the kernel-devel rpm has to be made available on the server side > along with cgi-scripts that can do the magic of generating new rpms on > demand. > > > Plus, some srpms only builds driver for the current running kernel by > > default, so you might need to tweak that as well. > > > > Have you take a look at dkms, also another DELL project, instead? > > http://linux.dell.com/projects.shtml > > > > dkms will allow clients to build drivers for new kernels dynamically, > > since when the new kernel boots dkms_autoinstaller will create the > > appropriate driver for it. Converting an srpm to dkms rpm is actually > > quite easy. I've managed to create dkms rpms for qlogic HBA driver > > (v8.01.07) and RHEL5's gfs (v0.1.16) the same day I found out about dkms. > > > > This should solve most driver problems. For qlogic HBA (or any scsi > > driver, I think), you need to reboot twice, as it will also update > > initrd which will only be used on the next reboot. > > True. But DKMS solves a different set of problems. In my case I dont > have source rpms, but only binary drivers packaged in rpms in a > repository. > And the requirement is ability to automatically provide rpms for all > future kernels. Sounds like you want to provide a way to provide only binaries to your customers? This sounds like an exceedingly bad idea. You will need to account for kernel api breakage, ie. some reporting mechanism when your autobuild fails to build new kernels. For the plugin, you want almost *exactly* the same plugin that I have written for dellsysid. Look here: http://linux.dell.com/libsmbios/download/firmware-addon-dell/firmware-addon-dell-1.2.13/firmware-addon-dell-1.2.13.tar.gz In the yum-plugin/ directory. You literally just need to change about 10 lines of code. Drop references to sys_{ven,dev}_id and replace with kernel{ver,arch}. Note that this plugin supports the new postconfig_hook that Seth has proposed, but this code isnt in yum yet. when it does go in, this plugin should be both forward and backward compatible. Next, for the server side, you can look at the mirrors.pl source for my repo here: http://linux.dell.com/repo/software/mirrors.pl-SOURCE You would just add code to pull out the version/arch and check for the packages and build, if necessary, and run createrepo, if necessary. I'll just say again, if the intent of this is to keep from providing source to your customers, this would be ill-advised. > I imagine this dynamic-repository idea can be used with dkms on the > server side. Because dkms can generate rpms on the server on-demand > using the driver sources.(offcourse you would need kernel-devel rpm on > the server side too). I'm pretty sure that this would work just fine as you describe. (mock would probably be helpful as well...) -- Michael _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxxxxx https://lists.dulug.duke.edu/mailman/listinfo/yum
