[OpenAFS] Re: kmod-openafs versioning on RHEL5

[Axel Thimm]

--0OAP2g/MAC+5xKAE
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Mar 16, 2008 at 03:15:33PM -0400, Derrick Brashear 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-2.2.6.18_53.1.4.el5 is
> > newer than kmod-openafs-1.4.5-1.2.6.18_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.
>=20
> He upgraded kernels, while at the same time (attempting) to downgrade
> openafs rpm versions.
>=20
> 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.

No, you're in the same trap again: There are two upgrade paths making
the usually one-dimensional problem a two dimensional one and as we
know there is no natural ordering in two dimensional systems.

Which means that one need to assign one dimension to the rpm upgrade
path and neutralize the other. The choice that makes sense as it is
handled in such a way already is to neutralize the kernel versioning,
e.g. considering equivalence classes (or strains) of packages.

In that sense even trying to compare packages of different module
version and different kernel versions is bogus to begin with. You may
consider different definitions of what versioning dimension needs to
be considered and what not, the main part is that you cannot compare
both.

Or rephrased: What module is "better"? The one for the newer kernel or
the one with the newer module version? Are they comparable? Should
they be? What kind of projection from the two-dimensional version
space to one ordering dimension can justify that? The answer is that
yum compared two entities that shouldn't be comparable to begin
with. And while yum may technically be correct the design certainly is
not.

Anyway this digresses too deep into package theory and I can live with
agreeing to disagree.

> >  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)
--=20
Axel.Thimm at ATrpms.net

--0OAP2g/MAC+5xKAE
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFH3YM+QBVS1GOamfERAo6NAJ4oF0n+syugxa7UAphdu8nodN6z8wCfXyVC
YyOnlOP75YlNyMGlgKSH6v8=
=q+on
-----END PGP SIGNATURE-----

--0OAP2g/MAC+5xKAE--