https://bugzilla.redhat.com/show_bug.cgi?id=2247350 --- Comment #36 from Fabio Valentini <decathorpe@xxxxxxxxx> --- (In reply to Kent Overstreet from comment #35) For context: I am a member of the Fedora Packaging Committee, the Rust SIG (and the developer and maintainer of the current version of the Rust packaging tools), and of FESCo, but I'm not responding here with that hat on. To me, it looks like there are some underlying misunderstandings here about how Linux distributions "work" (Fedora, in this case) - I've tried to address some of your points from the previous comment below. > 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. To the contrary - Fedora packages *MUST* be built with the default compiler flags set by the distribution - calling this "monkey-patching" is not accurate. Unless there are actual problems that are caused by some flags, just disabling them is not OK. > 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 I'm sorry, but I really don't understand this argument. I assume we don't even use the same C / Rust compilers (or the same versions) - I really hope you don't want us to ship and use the same version of the C / Rust compilers and the linker that you used to build and test, too? > 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. LTO is not a "strange build configuration". It's been enabled by default distro-wide in Fedora 33, about *three years ago*: https://fedoraproject.org/wiki/LTOByDefault Fedora is also not special here - some other distributions have defaulted to building with LTO enabled for even longer than that. > Regarding use of dependencies from cargo vs. distro: again, I don't want > users running something I haven't tested. This is also out of your hands, given how packaging works, be it Rust or C or whatever - you just *cannot* guarantee (or expect) that we will ship the exact versions of dependencies that you tested with - or the same version of the C / Rust compiler that you compiled your tests with, for what it's worth. Making sure that the packages that *we* ship actually work is also not *your* responsibility, but that of the *packager*. > 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. This is not the first project that's written in Rust that now makes up some kind of critical component in Fedora - even RPM itself now has dependencies that are written in Rust. The way we package components like these has never caused any "subtle" issues like the ones you're thinking of here. > 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. That's just asking us to reinvent the wheel. We *already have* a way to vet and audit projects from language-specific package ecosystems. ... by providing them as packages. > 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. There is no advantage for "runtime overhead", but there are other advantages to packaging Rust crates individually (for example, the "vetting/auditing" thing). Also, all that is somewhat irrelevant to this review ticket - you are neither the person who submitted the package for review, nor the person who is doing the review. While upstream project developer's opinions can - and do - inform how we do *some* things, they cannot override rules that we have for good reasons. -- You are receiving this mail because: You are always notified about changes to this product and component You are on the CC list for the bug. 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%23c36 -- _______________________________________________ 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
