On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling tbowling@redhat.com wrote:
Regarding these two questions:
Are there any concerns about such change? I believe that >90% users wouldn't notice anything as it's related to the history database only.
On Wed, Jul 18, 2018 at 10:01 AM Igor Gnatenko ignatenkobrain@fedoraproject.org wrote: Since we've changed the database entirely, what's the point of keeping same algorithm for calculating checksum?
On Wed, Jul 18, 2018 at 9:34 AM Daniel P. Berrangé berrange@redhat.com wrote: What's the benefit in changing to be compatible with YUM as opposed to stickin with current alogorithm ?
Surely if we don't change it, even fewer users will notice that DNF's behaviour is different from YUM's, since DNF has been the default for many releases now.
I could understand the motiviation to stay compatible with YUM if we were only just about to switch Fedora from YUM to DNF, but time is way in the past now. Shouldn't we optimize for the fact that DNF is the more widely deployed & used tool, and thus not worry about YUM compatibility in respect of the history DB ?
It is true that going forward in the Fedora world it matters less. It is more of an impact for yum-3 compatibility as yum4/dnf is being considered in the RHEL7/CentOS7 userspace environments as described at https://blog.centos.org/2018/04/yum4-dnf-for-centos-7-updates/
Currently yum version 3 and what the proof-of-concept project is calling yum4 work very well together side by side. Users can safely switch back and forth. The major problem is yum/dnf histories being different and the rpmdb checksum difference is a blocker for resolving the history compatibility.
So think of this as an effort to bring package management parity between Fedora, RHEL 7, & CentOS7, as the latter two still have a long life ahead of them.
Is there a reason why we can't change YUM to match the DNF behavior? IMO, the YUM behavior is nonsense and isn't even a valid package identifier.