On Mon, Aug 14, 2006 at 06:02:51PM +0200, Thorsten Leemhuis wrote: > > > Tom 'spot' Callaway schrieb: > > On Mon, 2006-08-14 at 16:06 +0200, Thorsten Leemhuis wrote: > >> Tom 'spot' Callaway schrieb: > >>> On Sat, 2006-08-12 at 17:18 +0200, Axel Thimm wrote: > >>> > >>> So far, the only technical reason that I've heard mentioned here against > >>> adding kver to Name is that it would make debuginfo more complicated for > >>> kmod packages (and I believe that someone posted a workaround method). > >> You forgot the biggest "issue" (note the quotes): All the depsolvers > >> would need special handling to install kmods for newly installed > >> kernels. That works out of the box with the current scheme and IMHO is > >> an important advantage of the current standard. Yes, there exists a > >> yum-plugin already that handles it. But we would need something for > >> up2date/RHEL5 too in case the ABI breaks -- I suspect that's to late. > > > > I'm not sure I see how this automatically works in the current kmod > > scheme > > Example (without a special plugin): > --- > Installed are: > kernel-2.6.17-1.2157_FC5 > kmod-foo-1.2.2.6.17-1.2157_FC5 > > kernel-2.6.17-1.2171_FC5 and kmod-foo-1.2.2.6.17-1.2171_FC5 are pushed > to the repo > > Yum will install: > kernel-2.6.17-1.2171_FC5 > kmod-foo-1.2.2.6.17-1.2171_FC5 > --- > > (or alternately, how it doesn't work in the kmod+kver scheme). > > Example (without a special plugin): > --- > Installed are: > kernel-2.6.17-1.2157_FC5 > kmod-foo-2.6.17-1.2157_FC5-1.2 > > kernel-2.6.17-1.2171_FC5 and kmod-foo-2.6.17-1.2171_FC5-1.2 are pushed > to the repo > > Yum will install: > kernel-2.6.17-1.2171_FC5 > > kmod-foo-2.6.17-1.2171_FC5-1.2 won't get installed because it a new > package for yum whit a different name > --- > > >>> In fact, I suspect that kmodtool could even include the necessary magic. > >> Sure, that would be possible. But we'll hit other problems after this > >> major scheme change. We probably hit some in the old livna days, but I > >> forget most of them already (sorry -- maybe I can skip though bugzilla > >> to fresh up my mind). But I think sticking to the current scheme and > >> solving the "install-conflicts" problem together with the kabi stuff > >> would be the better idea. > > > > Again, I tend to defer to people who know more about packaging kernel > > modules than I do. > > I'll outline my idea in a more detailed mail I'll start preparing now. > > CU > thl > > -- > Fedora-packaging mailing list > Fedora-packaging@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/fedora-packaging Thorsten, +1 This lack of functionality is a complete show stopper. I've been using a very similar method to the kmod example above for 6+ years. Its not been Pain Free(tm) but I have to have an automated system of deploying updates and kernel modules. Its just not an option or something that I will gladly re-invent. Jack -- Jack Neely <jjneely@xxxxxxxx> Campus Linux Services Project Lead Information Technology Division, NC State University GPG Fingerprint: 1917 5AC1 E828 9337 7AA4 EA6B 213B 765F 3B6A 5B89 -- Fedora-packaging mailing list Fedora-packaging@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-packaging
