On Wed, Apr 25, 2007 at 10:45:32AM -0700, Ram Pai wrote:
> On Wed, 2007-04-25 at 06:46 -0500, Michael E Brown wrote:
> >
> > 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}.
>
> I have to still sharpen my understanding yum-internals. But based on
> what you say, it feels encouraging.
My yum-fu is not that great, either, but I managed to muddle through it.
If you understand python at all, it should be *really* straightforward.
Thinking about this a little more...
The outline described will work for the case where you run yum-update
once to get new kernel, then again to get new kmod updates. (You cannot
fill in new $kernel{ver,arch} until new kernel is installed.)
So... if you want to enhace things by installing new kmod packages at
the same time as the kernel, you are going to have to do a lot more
work. You will have to check the proposed transaction for kernel
packages, then talk to your cgi script to get a package built at that
time for the kernel that is *about* to be installed. This makes for a
nicer user experience, but ends up being a more complicated plugin.
You might be able to look at the 1) installonlyn and 2) yum-presto
plugins to get ideas for how to implement this. The installonlyn plugin
does munging of the transaction based on which packages are
to-be-installed. The yum-presto "subverts" the whole package download
process in a way very similar to how you will probably need to do it.
In any case, I think that you can definitely get a workable solution
using a yum plugin and a server-side cgi.
> > I'll just say again, if the intent of this is to keep from providing
> > source to your customers, this would be ill-advised.
>
> No way. The intent is not that. The source rpms will be available,
> and can be used if ABI breakages are detected. But prefer to just
> use binary rpms if ABI is intact.
Great! Your first message could be read a couple different ways. I'm
happy to hear that you guys are not jumping on the binary-only package
bandwagon.
--
Michael
_______________________________________________
Yum mailing list
Yum@xxxxxxxxxxxxxxxxxxxx
https://lists.dulug.duke.edu/mailman/listinfo/yum
