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

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

 



On Wed, Jul 18, 2018 at 6:02 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote:
>
> On Wed, Jul 18, 2018 at 03:24:54PM +0200, Daniel Mach wrote:
> > Hi everyone,
> > The DNF team is currently reviewing DNF compatibility with YUM 3 and we'd
> > like to get feedback on this one:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1120253
> >
> > rpmdb checksum is a checksum of all installed RPMs
> > It has no cryptographical value, it's just an unique ID of RPMs on a system
> > before and after each transaction and it's used in dnf history info and dnf
> > history list.
> > If checksums of 2 following transactions do not match, DNF indicates that.
> > This happens if a user installs an RPM by hand via rpm command.
> >
> > Then `dnf history list` looks like:
> >      2 | install bar | 2018-01-01 02:00 | Install        |    2  <
> >      1 | install foo | 2018-01-01 01:00 | Install        |    7 >
> > the "<" and ">" characters indicate discontinuity in rpmdb hashes
> >
> > Here's the question:
> > DNF computes the checksum from RPM N-E:V-R.A
> > while YUM computed it from E:N-V-R.A
> >
> > We'd like to change the behavior to be compatible with YUM again.
> > This would create 1 discontinuity in rpmdb checksums in the history,
> > because from that point a new algorithm will be used.
> >
> > 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.
>
> 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 ?
>

>From my point of view, I considered YUM's rendering of the NEVRA to be
very weird. Personally, I'd rather see us keep the DNF behavior for
rendering NEVRA rather than switch to YUM's ENVRA.


-- 
真実はいつも一つ!/ Always, there's only one truth!
_______________________________________________
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/M3R625RUZ3URXB4FHWSDJ2G3HF7BMIE5/




[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