On Thu, 2 May 2019 at 20:29, Nicolas Mailhot via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: [..] > > IMO maintainer in this case is 100% right because all properties of > > the build env already can be described in with enough precision. > > Providing more details about build env will be duplicating current > > build dependencies. > > You're confusing constrains (build dependencies) with actual build env > composition (exact constrains resolution, which has been known to > change even with the same package set, just by switching dependency > resolution engines from yum to dnf to whatever). > > Build env composition information is generally useful for audits, > reproducibility, and debugging. It's useful enough to have been > reimplemented over the years in multiple places (elfutils spec, koji, > whatever). It's even more useful with the recent tendency to static > build. > > What is missing is a mecanism to record in in a generic way package- > side, so one does not have to rely on build farm logs (that may or may > not be retained over time) to access this basic info. > > Computing this info is trivial. It’s just a rpm -qa at the end of > buildrequires resolution. Accessing this info reliably, however, it not > trivial today, because the storage part has not been streamlined. As I wrote problem only is that without possibility really rollback to the full state described in set of exact N-E:V-Rs packages recorded data such auditing data in case if something starts going wrong such data could be used only as kind of murky vector where possible cause really is. It is nothing wrong with keeping only latest versions of the packages but with that assumption to have enough effectiveness of catching errors/issues needs to be added more test units fired straight after package build is done or during that process. Just look on some numbers below: [tkloczko@domek SPECS.fedora]$ grep ^%check *| wc -l; ls -1| wc -l 11692 21300 and the same stats on results of my own work: [tkloczko@domek SPECS.g2v]$ grep ^%check *| wc -l; ls -1| wc -l 426 498 Do you see where my thoughts are heading? With that only in last 3-4 months I've been able to catch maybe even few tenths of new issues just right on build packages (you can check stat of my accounts on gitlab and github to be able spot that part of my activity). I fully understand why Fedora keeps only latest versions of the packages and it is nothing wrong with that. Problems only is that if that small bit must be kind of assumption other parts around needs to be readjusted to create kind of strategy catching and dealing with new issues. And again .. with assumption that during packages development process never would be possible to fully rollback to the same N-E:V-Rs state storing build time metadata is kind of pointless (IMO). In other words reproducibility of those N-E:V-Rs metadata in case of Fedora are very close to *null*. BTW: storing all N-E:V-Rs of the *packages* could be easily solved by move away from rpm to IPS and I know that in case of the Fedora that kind of change is unrealistic. Adapting rpm to use packages repository like it is in case of IPS is unrealistic as well .. because to many things around needs to be changed (not only on packaging and distribution layer). You can observe this kind of effect on for example Sol 11.4 packages http://pkg.oracle.com/solaris/release/en/ The same web interface which immanent part of the IPS provides very long list of all version of the packages if you would be able to observe all Solaris SRUs (Service Recommended Updates) data. On Solaris 10 with IPS is possible even rollback to the state ~10 years old. Full rollback to the system state of all packages from the past is sometimes really important and this is why in OL repositories are never deleted older packages (yum/dnf repo allows keep multiple E:VRs of the same package in single repository). kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH _______________________________________________ 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
