On Mon, Aug 14, 2006 at 08:47:18PM +0200, Thorsten Leemhuis wrote:
>
>
> Jesse Keating schrieb:
> > On Monday 14 August 2006 14:06, Thorsten Leemhuis wrote:
> >> Yum will install:
> >> kmod-foo-1.3.2.6.17-1.2171_FC5
> >> *and remove*
> >> kmod-foo-1.2.2.6.17-1.2157_FC5
> >> kmod-foo-1.2.2.6.17-1.2171_FC5
> >> in the same transaction because the module location of
> >> kmod-foo-1.2.2.6.17-1.2171_FC5 and kmod-foo-1.3.2.6.17-1.2171_FC5 would
> >> conflict. *This remove is the problem Axel complains about.*
> > I could see it removing kmod-foo-1.2.2.6.17-1.2171_FC5, but why does it also
> > remove kmod-foo-1.2.2.6.17-1.2157_FC5? Wouldn't that be in a different
> > module tree?
>
> Well, normally it's a "install transaction" but when there is a
> potential file conflict it's changed to a "upgrade transaction" afaik --
> and that will remove the old kmod as well because both old kmods have
> the same packagename.
This is not correct. The current implentation will install the new
module and add an erase transaction element for the old module requiring
the same kernel.
>
> >> == Proposed solution ==
> >>
> >> Install the kernel-module to
> >>
> >> /lib/modules/kabi/MODULE/VERSION-RELEASE/{MODULES...}.ko
> >>
> >> and remove the
> >>
> >> "Requires: kernel<?kernel-flavour>-<?kernel-version>
> >>
> >> Details:
> >>
> >> We avoid the file conflicts noted in "Problem" above due to the
> >> "VERSION-RELEASE" in the path. So yum will always install the module and
> >> there won't be any conflicts.
> >>
> >> But how will the kernel find the module there? "/sbin/weak-modules", the
> >> script from the kabi stuff can create links to the proper places. It
> >> does this already for modules installed in the proper place and kernels
> >> that have the compatible kabi. It would be needed to adjust some
> >> pathnames in the script, but that shouldn't be to hard.
> >>
> >> And why remove the Requires? Well, with the kabi stuff it might happen
> >> (not that often in Fedora, but on RHEL often) that a module runs fine on
> >> a newer kernel. We wouldn't have to build a new module in that case.
> >> *But* this requires would fire back because the kmod will get removed by
> >> the depsolver when the kernel is was build for gets uninstalled.
> >> Therefor it needs to be removed.
> >
> > Also, with the kabi stuff, the Requires should get done automatically to an
> > ABI version. If the next kernel has an ABI change, and you rebuild the
> > module, thats cool, it picks up the new ABI in the automatic Requires. No
> > manual intervention.
>
> That would solve the problem nicely.
>
> > I would _really_ like to get JCM involved in this discussion, especially on
> > the proper place to drop these modules so that a respin for one kernel won't
> > remove modules from an older kernel.
>
> +1
>
> CU
Generally, kabi sucks less, so +1
Right now I use the Requires: kernel-i686 = 2.6.14-1.1776_FC4 to figure
out what kernel we match, but that's easy to fix.
Jack
> thl
>
> /me going to bed now soon
>
> --
> Fedora-packaging mailing list
> Fedora-packaging@xxxxxxxxxx
> https://www.redhat.com/mailman/listinfo/fedora-packaging
--
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
