On Tue, 2007-04-24 at 13:29 -0500, Michael E Brown wrote: > On Tue, Apr 24, 2007 at 11:24:27AM -0700, Ram Pai wrote: > > On Tue, 2007-04-24 at 08:51 -0500, Michael E Brown wrote: > > > On Mon, Apr 16, 2007 at 02:34:58AM -0700, 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. In all probability the driver present in the rpm for a > > > > older kernel will suffice since the kernel's ABI would'nt have changed. > > > > In such cases the driver rpm for the new kernel can be built dynamically > > > > in the repository, reusing the driver in a existing rpm. > > > > > > > > However I find that even if these rpms can dynamically be made > > > > available on demand by the yum client, the yum protocol does not lend > > > > itself to handle these dynamically generated rpms. > > > > > > > > Does anybody know of ways this can be handled with existing > > > > infrastructure? > > > > > > > > I am thinking may be createrepo is augmented to generate xml files, > > > > which somehow convey to the client that some rpms can be made available > > > > on-demand. Will that work? Looking for ideas/suggestions. > > > > > > Ram, > > > After mulling on this a little bit, how about this idea: > > > > > > You could create a yum plugin that sets yumvars: $kernelver and > > > $kernelarch. Then you could set up the repo with > > > > > > mirrorlist=http://your.site/mirror.cgi&kernelver=$kernelver&kernelarch=$kernelarch > > > > > > In your CGI script, you could detect if modules for that kenrel are > > > built. If they are, return the repo baseurl. If they are not, build the > > > packages and update the repo metadata before returning the baseurl. > > > > Interesting. Sounds like this skips the xml file download, and directly > > installs the rpm of interest. Am I thinking right? > > No, it doesnt. It just delays downloading the xml metadata until the new > package is in the repo and ready to go. Sort of a behind-the-back magic. > > The yum client says, "hey can you give me the mirrorlist, and by the > way, here is some other information you might be interested in > ($kernelver, $kernelarch, etc)" > > The cgi on the server says, "yeah, umm.... (swizzles repository in the > background) ... here you go. Here is the repo with everything you need." /me smiles. neat. Will try this out. This solution will still need a plug-in on the client side, to be downloaded from somewhere. And I am sure the cgi script has to be fast enough for the client to not timeout. A capability in the client tools to handle xml files, that says "I dont have this rpm in the repository yet, but I can make it for you if you demand" will be nice. RP > > -- > Michael > _______________________________________________ > Yum mailing list > Yum@xxxxxxxxxxxxxxxxxxxx > https://lists.dulug.duke.edu/mailman/listinfo/yum _______________________________________________ Yum mailing list Yum@xxxxxxxxxxxxxxxxxxxx https://lists.dulug.duke.edu/mailman/listinfo/yum
