On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling
<tbowling(a)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(a)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(a)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.
What about all the enterprise applications and other traditional
platforms that are deployed that expect the existing functionality or
outcomes, not saying it's necessarily correct but there's a lot of
technical debt out there. In a lot of cases there's legacy out there
that needs to be supported and that requires existing APIs to work as
they currently do so there can be migrations.
Peter