On Thu, Jul 19, 2018 at 12:06 AM, Neal Gompa <ngomp...@gmail.com> wrote:
> On Wed, Jul 18, 2018 at 6:02 PM Daniel P. Berrangé <berra...@redhat.com> > 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@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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@lists.fedoraproject.org/message/DUFU46D7NU3AFU3ZEP4ES6MJRIUVZD24/
