[OpenAFS] Re: kmod-openafs versioning on RHEL5
Sun, 16 Mar 2008 15:15:33 -0400
On Sun, Mar 16, 2008 at 7:40 AM, Axel Thimm <Axel.Thimm@atrpms.net> wrote:
> On Sun, Mar 16, 2008 at 10:44:26AM +0000, Simon Wilkinson wrote:
> > On 16 Mar 2008, at 09:02, Axel Thimm wrote:
> >> On Sat, Mar 15, 2008 at 08:01:46PM -0400, Derrick Brashear wrote:
> >>> On Sat, Mar 15, 2008 at 6:22 PM, Axel Thimm <Axel.Thimm@atrpms.net>
> >>> wrote:
> >>> YHO doesn't help that he's trying to use an older minor revision of
> >>> the RPMs he's using with a newer minor revision of modules; The kernel
> >>> version is entirely irrelevant.
> >>> foo-1-(`uname -r`) would still be older than foo-2-(`uname -r`).
> >> No, look closer and you'll see that he has two different uname-r, not
> >> the same. And by the very construction of the uname-r-in-name scheme
> >> this comparison cannot and shouldn't be done.
> > Erm. No. The problem here was that the OP had built his first kernel module
> > (and userland) from openafs-1.4.5-2.el5, and his second kernel module from
> > openafs-1.4.5-1.el5. The upgrade failure was entirely because the second
> > module was built from an earlier OpenAFS RPM, and not any problems with the
> > uname -r location in the kmod scheme. You may be right about the benefits
> > of kmdl vs kmod, but they just aren't relevant to this case.
> Well, the OP wrote in the first post: "Yum refuses to install the
> package claiming that kmod-openafs-1.4.5-126.96.36.199_53.1.4.el5 is newer
> than kmod-openafs-1.4.5-188.8.131.52_53.1.13.el5."
> This is 1.4.5-2 built for 2.6.18_53.1.4.el5 vs 1.4.5-1 built for
> 2.6.18_53.1.13.el5. These builds are for *different kernels* and
> having a depsolver forbidding to use different versions of the module
> for different kernels is a bug.
He upgraded kernels, while at the same time (attempting) to downgrade
openafs rpm versions.
yum *correctly* refused to installed the openafs-1.4.5-1 for his newer
kernel when 1.4.5-2 was already running with his older one.
> Building foo-1 vs foo-2 on different kernels is a valid case and
> sometimes even required (for example wireless drivers for the
> different RHEL5 kernels with differently pacthed wireless subsystems)
> Axel.Thimm at ATrpms.net