On Thu, Jul 19, 2018 at 3:26 PM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling <tbowling@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx/message/YNSIGFNMX5POCDRGKVUEFWXQCD4DLVV2/
