https://bugzilla.redhat.com/show_bug.cgi?id=2247350 --- Comment #35 from Kent Overstreet <kent.overstreet@xxxxxxxxx> --- So in conversation with Eric a few other things came up - LTO builds, for one. Besides swapping out/devendoring dependencies, I need to ask that packagers be restrained in what else they change about how bcachefs-tools is built - if there's something you'd like to change/enable, like LTO, please do it by submitting a patch to bcachefs-tools and not monkey-patching in the rpm build process. We need to make sure that people using bcachefs are using packages that have been properly tested; that means running code that's built the same way as what my test infrastructure uses: https://evilpiepirate.org/~testdashboard/ci LTO is great, but it's not something that we can flip on without testing; there's particular cause for concern here because bcachefs-tools is a mixed C and Rust project, and by default links gcc and llvm output together. In kernel land this works - but not necessarily when you get into strange build configurations, of which LTO is one. Regarding use of dependencies from cargo vs. distro: again, I don't want users running something I haven't tested. Keep in mind that we're talking about filesystem tools here, so any mistake may result in users not being able to boot their machines. And I do mean any mistake; for example clap (which we use for argument parsing) may seem like something trivial that distro packagers can swap out for a different version without cause for concern - but if a change in argument parsing results in subtle breakage, then our mount helper may break and users won't get out of their initramfs. That won't be fun for the average user to recover from. I understand that distro people have concerns about proper vetting/auditing of packages from other package managers, and I'd like to see those taken up - by working with the Cargo people. I also need to note that Rust doesn't yet support dynamic linking across crates (with #repr(Rust)), so there's no advantage to de-vendoring packages as far as runtime overhead. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=2247350 Report this comment as SPAM: https://bugzilla.redhat.com/enter_bug.cgi?product=Bugzilla&format=report-spam&short_desc=Report%20of%20Bug%202247350%23c35 -- _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
