On Thu, Jul 19, 2018 at 12:06 AM, Neal Gompa <ngompa13@xxxxxxxxx> wrote:
That's right, we definitely don't want to go back to ENVRA anywhere in the UI or API.From my point of view, I considered YUM's rendering of the NEVRA to beOn 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 ?
>
very weird. Personally, I'd rather see us keep the DNF behavior for
rendering NEVRA rather than switch to YUM's ENVRA.
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/
