[OpenAFS-devel] Re: pagsh in krbafs vs openafs

[Axel Thimm]

--ZfOjI3PrQbgiZnxM
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

as an update beforehand: this discussion stirred up a review about
krbafs-utils in Fedora which ended in this package being dropped for
future Fedora (and thus RHEL) releases. E.g. it is now a discussion
about how to deal with the *legacy* of krbafs-utils in RHEL3/4 and
FC6/F7.

On Mon, Aug 20, 2007 at 06:32:22PM -0400, Jeffrey Hutzelman wrote:
> >>>what about putting a "conflicts" or "obsoletes" rpm field in there?
> >
> >>If that solves the issues I'm all for it.
> >
> >That's probably a good idea.
>=20
> We certainly could conflict with krbafs-utils, though that would be a bit=
=20
> odd, since what other AFS is there for those distributions?

Why would that matter?

> OTOH, since we provide conflicting versions of the same file, RPM
> should _already_ be treating them as conflicting,

Yes, but *file conflicts" are a bad thing in comparison to package
conflicts. The latter can be taken in consideration by the depsolvers.
In fact all of yum/apt/smart deal properly with a package
obsoleting/conflicting another package while they fail on file
conflicts. What happens is that the depsolver considers the package
(co)installable and passes the install op command to rpm(lib). Them
rpm fails and the depsolvers cannot recover anymore.

> and since that's the only true conflict, the only thing that
> asserting a conflict would do is uselessly insure you can't install
> the two packages at the same time even if _they_ rename away the
> conflicting files.

No, most depsolvers know how to deal with it by removing the other
package. Certainly for Obsoletes: and most depsolvers even for
Conflicts:

> Trying to obsolete krbafs-utils is almost certainly a bad idea.

Why? The upstream vendor also agrees that krbafs-utils has been
rotting in the distribution for far too long and dropped it for future
ones (he can't simply remove it for released ones, of course). The
functionality is being superseeded by the openafs bits, so both the
upstream vendor and the openafs project agree that the openafs
components are a better replacement for krbafs-utils.

> Note that Fedora does have alternatives, which could certainly be used to=
=20
> resolve this conflict in future releases.  However, it requires all=20
> packages providing the conflicting files to participate, so coordination=
=20
> with the maintainer of krbafs-utils would be required.

Well, the maintainer of krbafs-utils moved the files in /dev/null, so
we could only have symlinks to /dev/null for the krbafs-utils
alternative :)
--=20
Axel.Thimm at ATrpms.net

--ZfOjI3PrQbgiZnxM
Content-Type: application/pgp-signature
Content-Disposition: inline

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

iD8DBQFGyhosQBVS1GOamfERAh2GAJsF56vUbZOD/6CV2Vql55v+4/c52QCfRFBm
ap/Vn+Gjm67Yv+MdwfkasLQ=
=MTkx
-----END PGP SIGNATURE-----

--ZfOjI3PrQbgiZnxM--