Re: dnf history - change in how rpmdb checksum is computed
On Tue, Jul 31, 2018 at 09:06:13AM +0200, Michael Mraka wrote: > > > > 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. > > So if you want make world a better place stick with current dnf format. I think this, with the combination of earlier suggestion, is the best solution for Fedora. So: 1) make yum calculate checksum primarly with DNF format 2) when there's a discrepancy, let yum calculate csum in legacy yum format This way: - dnf is not bothered - users of yum have continuous history - new yum users have checksum calculated in better way Win-win! -- Tomasz TorczOnly gods can safely risk perfection, xmpp: zdzich...@chrome.pl it's a dangerous thing for a man. -- Alia ___ 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/TT3ZVQBBJGQGQYIVOWBC7L6Y2D5WCF4J/
Re: dnf history - change in how rpmdb checksum is computed
On Tue, Jul 31, 2018 at 3:40 PM Michal Novotny wrote: > On Tue, Jul 31, 2018 at 1:25 PM Jeff Johnson wrote: > >> This simply is not true. >> >> Whatever "rpm format" means, historically RPM itself has always gone to >> some lengths not to expose E: to users to simplify the endless fog of >> dependency hell clutter. >> > > Yeah, something which is eluding my understanding. > > This will be all off-topic by me again but I think it might be worth to be > mentioned at least... > > Given that epoch plays an important role in version comparison (therefore > during package upgrades), it should be visible in rpm names. > > E.g. > > $ rpm -q bind-libs > > should return: > > bind-libs-32:9.11.3-6.fc28.x86_64 > > on my system. > > It should be clear directly from package name why e.g.: > > bind-libs-32:9.11.3-6.fc28.x86_64 < bind-libs-33:9.9.4-61.fc28.x86_64 > > Hiding the epoch does not serve any purpose here (or anywhere). Epoch > number is something that should be explicitly present in package name so > that > users know what's going on when they can't update a package. > > Of course, ideally epoch should stay zero if possible and only be used as > a "safety mechanism" when upstream does something unexpected but even if > epoch is zero, > it should still be put into rpm name. > > This is very remotely related to: > https://github.com/rpm-software-management/rpm/issues/450 > > clime > > P.S.: note that if Epoch: tag is missing in a spec file, it should be > assumed epoch = 0. I think the behavior I am describing is quite natural, > that's why I am using the word "should". > Sorry for the tone in this sentence. I just think rpm is a bit needlessly "bent" in these areas. clime > > ___ >> 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/XHYTGM2L7PNOWNYKA6T26B7ACDGMX3DD/ >> > ___ 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/E2IUSM4JGEEE7ZJ34B3FBCOT5PHRUQ2P/
Re: dnf history - change in how rpmdb checksum is computed
On Tue, Jul 31, 2018 at 1:25 PM Jeff Johnson wrote: > This simply is not true. > > Whatever "rpm format" means, historically RPM itself has always gone to > some lengths not to expose E: to users to simplify the endless fog of > dependency hell clutter. > Yeah, something which is eluding my understanding. This will be all off-topic by me again but I think it might be worth to be mentioned at least... Given that epoch plays an important role in version comparison (therefore during package upgrades), it should be visible in rpm names. E.g. $ rpm -q bind-libs should return: bind-libs-32:9.11.3-6.fc28.x86_64 on my system. It should be clear directly from package name why e.g.: bind-libs-32:9.11.3-6.fc28.x86_64 < bind-libs-33:9.9.4-61.fc28.x86_64 Hiding the epoch does not serve any purpose here (or anywhere). Epoch number is something that should be explicitly present in package name so that users know what's going on when they can't update a package. Of course, ideally epoch should stay zero if possible and only be used as a "safety mechanism" when upstream does something unexpected but even if epoch is zero, it should still be put into rpm name. This is very remotely related to: https://github.com/rpm-software-management/rpm/issues/450 clime P.S.: note that if Epoch: tag is missing in a spec file, it should be assumed epoch = 0. I think the behavior I am describing is quite natural, that's why I am using the word "should". ___ > 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/XHYTGM2L7PNOWNYKA6T26B7ACDGMX3DD/ > ___ 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/ZZTTRZEKH6KXH324OHN5Y44AUZU5RSHA/
Re: dnf history - change in how rpmdb checksum is computed
Jeff Johnson: > This simply is not true. What is not true? Could you please include sentence you are referring to? > Whatever "rpm format" means, historically RPM itself has always gone to some > lengths not to expose E: to users to simplify the endless fog of dependency > hell clutter. Rpm does not print epoch in in standard --query output only in --info mode. $ rpm -q bind-libs bind-libs-9.9.4-61.el7.x86_64 $ rpm -qi bind-libs Name: bind-libs Epoch : 32 Version : 9.9.4 Release : 61.el7 Architecture: x86_64 ... It understands N-V-R.A or N-E:V-R.A as an argument but not E:N-V-R.A. $ rpm -q bind-libs-9.9.4-61.el7.x86_64 bind-libs-32:9.9.4-61.el7.x86_64 32:bind-libs-9.9.4-61.el7.x86_64 bind-libs-9.9.4-61.el7.x86_64 bind-libs-9.9.4-61.el7.x86_64 package 32:bind-libs-9.9.4-61.el7.x86_64 is not installed -- Michael Mráka System Management Engineering, Red Hat ___ 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/4LNMWBXTPGWDYQCE2LJIVG6QCPDUH6FL/
Re: dnf history - change in how rpmdb checksum is computed
This simply is not true. Whatever "rpm format" means, historically RPM itself has always gone to some lengths not to expose E: to users to simplify the endless fog of dependency hell clutter. ___ 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/XHYTGM2L7PNOWNYKA6T26B7ACDGMX3DD/
Re: dnf history - change in how rpmdb checksum is computed
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 > >> 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é > >> 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@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/KXLUGD7446XWI4TS2ITKQ2JPUAGHEF5S/
Re: dnf history - change in how rpmdb checksum is computed
This thread was about compatibility between dnf and yum: rpm itself has no usage case identifying whether an rpmdb has been changed. But you are correct that installation of a package by any tool -- including dnf and rpm atm -- needlessly causes yum to warn that the rpmdb has changed which is rather silly IMHO. ___ 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/ZMU4CE2ZSHOSQCCG7AW6FXREDGCU3MNF/
Re: dnf history - change in how rpmdb checksum is computed
I would like to see dnf history not being messed up by direct installations with `rpm -i`. While `dnf history` is a great feature, it would be even greater if the related functionality was implemented directly in rpmdb and both rpm and dnf used that db. Meaning that any consistency checks would be in that db too. Just an idea. clime On Tue, Jul 24, 2018 at 12:40 AM Jeff Johnson wrote: > The real problem is that both E:N-V-R.A and N-E:V-R.A are equally > imprecise. > > The concept of "reproducible builds/installs" requires much more complete > identifiers for serious work. But that was not the question asked in this > thread. > > So calculating both checksums, on rearranged plaintext items, for > compatibility, kinda misses the underlying need to verify system installs > on hundreds of machines. > ___ > 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/G5PQ6DZKLVJJYPJCQG2VVQQMRAITETJ3/ > ___ 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/CVZAQ5IQATEMD6NTDUAQ47A2HWI6VMCV/
Re: dnf history - change in how rpmdb checksum is computed
The real problem is that both E:N-V-R.A and N-E:V-R.A are equally imprecise. The concept of "reproducible builds/installs" requires much more complete identifiers for serious work. But that was not the question asked in this thread. So calculating both checksums, on rearranged plaintext items, for compatibility, kinda misses the underlying need to verify system installs on hundreds of machines. ___ 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/G5PQ6DZKLVJJYPJCQG2VVQQMRAITETJ3/
Re: dnf history - change in how rpmdb checksum is computed
On 07/18/2018 09:24 AM, 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 Could we just update dnf/"newyum" to calculate both checksums and only represent the discontinuity if neither match? Obviously this increases the chance of a collision, but could put this conversation to rest. At some distant point in the future we can stop calculating 'E:N-V-R.A' since all new transactions would have been calculated based on 'N-E:V-R.A' Dusty ___ 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/2ZG45QT7AW54UKW2OVYTDHGF6OZ7VNXU/
Re: dnf history - change in how rpmdb checksum is computed
Use headerFormat() with a configurable format string to extract the package identifier item in the list that is check summed and have it both ways. Why anyone wishes to preserve compatibility with yum's bloated history database in order to flip between two depsolvers is left to RH TAM's to explain to customers. ___ 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/CT4KBPW6YAP6O6BJNU4UQQSHKGCR4I3Q/
Re: dnf history - change in how rpmdb checksum is computed
On Thu, Jul 19, 2018 at 12:06 AM, Neal Gompa wrote: > On Wed, Jul 18, 2018 at 6:02 PM Daniel P. Berrangé > 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/
Re: dnf history - change in how rpmdb checksum is computed
On Wed, Jul 18, 2018 at 5:13 PM, Ben Cotton wrote: > On Wed, Jul 18, 2018 at 11:02 AM Daniel Mach wrote: > > > If a user migrates from RHEL 7 to the next version of RHEL (or CentOS), > > there will be continuity in used algorithm and history db checksums. > > It's important to some enterprise customers to keep the history db in a > good shape. > > Fedora users don't care about that much in general. > > > This makes sense. Let me ask from another angle: does Fedora lose > anything from not using the current dnf history algorithm (apart from > the discontinuity when we switch)? Would it make sense to have that be > a configurable option where Fedora defaults to the dnf model and RHEL > defaults to the yum model or is it essentially a cosmetic difference? > To me, it's more a cosmetic difference and I don't think it deserves a configurable option for switching the behavior. It is more important to unify the behavior, document it and cover with tests. ___ 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/GGU7CFCTBGEVJOTD5TZFQTGS55P3NWUP/
Re: dnf history - change in how rpmdb checksum is computed
On Thu, Jul 19, 2018 at 3:26 PM, Neal Gompa wrote: > On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling wrote: >> >> 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 >>> 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é >>> 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. What about all the enterprise applications and other traditional platforms that are deployed that expect the existing functionality or outcomes, not saying it's necessarily correct but there's a lot of technical debt out there. In a lot of cases there's legacy out there that needs to be supported and that requires existing APIs to work as they currently do so there can be migrations. Peter ___ 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/YNSIGFNMX5POCDRGKVUEFWXQCD4DLVV2/
Re: dnf history - change in how rpmdb checksum is computed
On Wed, Jul 18, 2018 at 8:37 PM Terry Bowling wrote: > > 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 >> 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é >> 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. -- 真実はいつも一つ！/ Always, there's only one truth! ___ 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/SU43ILZ3GELAKUWQSM2345LK7PEKCQFE/
Re: dnf history - change in how rpmdb checksum is computed
On Wed, Jul 18, 2018 at 6:02 PM Daniel P. Berrangé 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@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/M3R625RUZ3URXB4FHWSDJ2G3HF7BMIE5/
Re: dnf history - change in how rpmdb checksum is computed
> If a user migrates from RHEL 7 to the next version of RHEL (or CentOS), > there will be continuity in used algorithm and history db checksums. > It's important to some enterprise customers to keep the history db in a > good shape. > Fedora users don't care about that much in general. I care about maintaining dnf history in Fedora, it is a very useful debugging tool. Seems like it is broken in rawhide: https://bugzilla.redhat.com/show_bug.cgi?id=1598590 Is the hash reason why dnf 1/2 history doesn't work with dnf 3? ___ 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/JJ4TGQNYLX5X2ESSXQD66WKWK5652AIA/
Re: dnf history - change in how rpmdb checksum is computed
On Wed, Jul 18, 2018 at 11:02 AM Daniel Mach wrote: > If a user migrates from RHEL 7 to the next version of RHEL (or CentOS), > there will be continuity in used algorithm and history db checksums. > It's important to some enterprise customers to keep the history db in a good > shape. > Fedora users don't care about that much in general. > This makes sense. Let me ask from another angle: does Fedora lose anything from not using the current dnf history algorithm (apart from the discontinuity when we switch)? Would it make sense to have that be a configurable option where Fedora defaults to the dnf model and RHEL defaults to the yum model or is it essentially a cosmetic difference? -- Ben Cotton Fedora Program Manager TZ=America/Indiana/Indianapolis ___ 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/GSTZHIJFNTIOW5FWNKZ7RK4CJOC7YRBU/
Re: dnf history - change in how rpmdb checksum is computed
On Wed, Jul 18, 2018 at 05:01:14PM +0200, Daniel Mach wrote: > > > > What's the benefit in changing to be compatible with YUM as opposed > > to stickin with current alogorithm ? > > > If a user migrates from RHEL 7 to the next version of RHEL (or CentOS), > there will be continuity in used algorithm and history db checksums. > It's important to some enterprise customers to keep the history db in a > good shape. > Fedora users don't care about that much in general. Creating incompatibilties for Fedora users to benefit RHEL users is not a very compelling argument to me. > > 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 ? > > > Unfortunately RHEL knows nothing about DNF yet > and it's YUM compatibility what matters. If DNF looks at the previous transaction and sees the checksum doesn't match that of the new transaction, could it fallback to re-calculate the checksum with the old algorithm and retry validation. It can then continue to use its current algorithm from that point onwards. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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/LQ2YS754Y2VKFDS4CPZ3EOS22AAZ6CAO/
Re: dnf history - change in how rpmdb checksum is computed
> > What's the benefit in changing to be compatible with YUM as opposed > to stickin with current alogorithm ? > If a user migrates from RHEL 7 to the next version of RHEL (or CentOS), there will be continuity in used algorithm and history db checksums. It's important to some enterprise customers to keep the history db in a good shape. Fedora users don't care about that much in general. > 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 ? > Unfortunately RHEL knows nothing about DNF yet and it's YUM compatibility what matters. ___ 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/JYCKOFC223P5RADHMZOBNBA5L2V6EGYS/
Re: dnf history - change in how rpmdb checksum is computed
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 < > ignatenkobr...@fedoraproject.org> 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é > 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. Hope that helps, Terry ___ 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/WP7IKLV2WYNMZBECWPOQL4VOEW4ZV3PL/
Re: dnf history - change in how rpmdb checksum is computed
On Wed, Jul 18, 2018 at 3:35 PM 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. > Since we've changed the database entirely, what's the point of keeping same algorithm for calculating checksum? -- -Igor Gnatenko ___ 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/NLVQBHD5DV3NCNY4S7P7WGDJ6PZHTJ5T/
Re: dnf history - change in how rpmdb checksum is computed
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 ? Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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/ZG6TW35U3RPAIRHOPCNR7P22ECQWJYC7/
dnf history - change in how rpmdb checksum is computed
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. thanks, Daniel ___ 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/YOYJEKGZ3N4Q67TVOQ6MHBK37RESBVAQ/
