Bug 31649

lib packages are not supposed to be obsoleted unless they interfere with
the new packages. The requires in gssproxy could be altered so ensure one of
the new packages does get installed, but the old lib should not be removed
unless absolutely necessary for the new package to work.

The reason old lib packages do not get obsoleted is to allow compatibility
with third party software.

Does gssproxy work with the older lib?

CC: (none) => davidwhodgins

Would it not be more sensible that 'gssproxy' works with one of the new proposed libraries? Of which 'lib64verto-libevent1' looks the closest.
This looks like a dependency problem for gssproxy, which guillomovitch looks after. So assigning this to him.

Assignee: bugsquad => guillomovitch

gssproxy is simply a dependency of nfs-utils, which works fine for me.
With the old lib and new lib gssproxy starts from the systemd-unit by using 'systemctl start gssproxy'. It also starts in both cases in interactive mode with 'gssproxy -i'.
I haven't tested any further functionality, since I don't really know or use the package.

I do understand the problem "should" be fixed in gssproxy deps. But since it is a virtual Provides for libverto-module-base, which is provided by lib64verto-event1 and lib64verto-ev1, and in mga8 also by lib64verto-tevent1, it might be a simple solution to have lib64verto-event1 obsolete lib64verto-tevent1. But I also understand that might be unwanted, and I have no clue if both libs are interchangeable in all ways.

Anyway, guillomovitch knows the package better, so I trust he knows how to work on this.

Just a thought. I can imagine gssproxy requiring libverto-module-base version >= 0.3.2. This would install a new mga9 package, leaving lib64verto-tevent1 from mga8 as a leaf orphan package that can be uninstalled easily.

Versionned dependencies are supposed to express software requirements, using them to force package upgrade between release seems a dirty hack. And I don't see any problem having leftover packages after an upgrade, as long as they work.
Feel free to force removal and reinstall if you're not confortable with.

Comment 4 is an appropriate solution. It ensures that a Mageia 9 version of
the libs is installed when upgrading from m8, so that the user can then
uninstall leftover m8 packages (if desired) without having gssproxy get
uninstalled too.

That would still be an ugly hack for a non-existing problem. Just prove there is  something wrong with this kind of situation, and not just a cosmetic issue, and I may reconsider my position, otherwise that's a wontfix for me.

If after m8 support ends, there is a security update that affects the m8
lib, then the users still using the m8 lib (which will be everyone using
gssproxy in m8 who then upgrade) will be left with insecure versions.

Putting in version+ specific requires could be done now, or at that time
provided this issue is not forgotten. It would require monitoring
libverto-0.3.1-2 for security issues for the duration of m9 support (possibly
longer) or until version specific requires do get added.

I opted for Fedora strategy instead:
- stricter version dependencies between main library package and its module
- obsoleting of old tevent module

This seems safer and more readable, as safe-contained in libverto package.

And the real issue here, actually, is why does anyone need a mandatory kerberos proxy for NFS, whereas I highly doubt any casual mageia user would ever use such kind of exotic configuration ?

Thank you, I can confirm that the upgrade works well.

And yes, if that proxy dependency would be removed for Mageia 10, there would be enough time for beta testers to complain, if they even use that :)

Resolution: (none) => FIXED
Status: NEW => RESOLVED