Re: dnf history - change in how rpmdb checksum is computed

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Neal Gompa:
> > 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.

Actually E:N-V-R.A is yum-ism no one else understand
while N-E:V-R.A is correct rpm format.

  $ rpm -q bind-libs
  bind-libs-9.9.4-61.el7.x86_64
  $ rpm -q 32:bind-libs-9.9.4-61.el7.x86_64
  package 32:bind-libs-9.9.4-61.el7.x86_64 is not installed
  $ rpm -q bind-libs-32:9.9.4-61.el7.x86_64
  bind-libs-9.9.4-61.el7.x86_64

So if you want make world a better place stick with current dnf format.


--
Michael Mráka
System Management Engineering, Red Hat
_______________________________________________
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/KXLUGD7446XWI4TS2ITKQ2JPUAGHEF5S/




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux