https://bugzilla.redhat.com/show_bug.cgi?id=2247350
--- Comment #36 from Fabio Valentini <decathorpe(a)gmail.com> ---
(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=rep...