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

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

 



On Thu, Jul 19, 2018 at 12:06 AM, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
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.

That's right, we definitely don't want to go back to ENVRA anywhere in the UI or API.
The ENVRA format would be only an implementation detail in the function that computes the checksum.
_______________________________________________
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/DUFU46D7NU3AFU3ZEP4ES6MJRIUVZD24/

[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