On 11/1/22 10:40, Matthew Miller wrote:
On Wed, Oct 19, 2022 at 01:04:39PM +0200, Fabio Valentini wrote:
> I'll respond inline.
Me too -- and apologies for the delay.
>> I fundamentally disagree with Kevin on a deep level about "entirely
>> useless", but ... find myself kind of agreeing about the
"unpackagable"
>> part. I mean: clearly we've found a way, but I'm really not sure
we're
>> providing a lot of _value_ in this approach, and I'm also not sure it's
>> as successful as it could be.
> We *do* provide value to both users *and* developers by doing things
> the way we do, but the benefits might not be obvious to people who
> don't know how (Rust) packaging works, and what we as package
> maintainers do.
Let me rephrase: I absolutely think you've provided value and are providing
value (and I appreciate it). I am not convinced that the value is in the
RPM-izing part, though.
Please do not stop packaging Rust crates. Qubes OS at least will be relying
on these packages to build its own Rust code in the not-too-distant future.
[...]
> This is due to a limitation of how cargo handles target-specific
> dependencies - all dependencies that are *mentioned in any way* need
> to be *present* for it to resolve dependencies / enabled optional
> features / update its lockfile etc. But since we don't want to package
> bindings for Windows and mac OS system APIs, we need to actually patch
> them out, otherwise builds will fail.
Theoretically, if we had our own crate repository, we could either make
those changes there (possibly using something like packit to carry the
patches) -- or, just, not make the changes and not worry because we know
those won't end up used anyway?
> You must realize that this is an extreme case. For many Rust
> applications that people want to package for Fedora, the number of
> dependencies that are missing is rather small, *because* most popular
> libraries are already packaged.
It may be that I just hear about the difficult cases.
Probably so.
> Sure, but isn't that the case for most projects that a
newcomer wants
> to package, regardless of programming language? Say, somebody wants to
> package some cool new Python project for machine learning, then
> there's probably also some linear algebra package or SIMD math library
> in the dependency tree that's missing from Fedora. How is that
> different?
Rust tends to be more fine-grained. I don't think this is necessarily
rust-specific _really_ — I think it's a trend as people get more used to
this way of doing things. With Python, there are some big packages
(including "batteries included" standard Python itself) which tend to group
big related sets of functionality. (notably: numpy, scipy, pandas...)
There is another factor that I think needs to be mentioned here:
In Rust, a crate is not only the unit of packaging, but also of
compilation. A project may well have several crates purely for
internal code organization or to reduce build time. Some of these
crates may never be intended for use outside of the larger project.
In this case, bundling them is absolutely the correct decision, as
nobody else should ever be depending on them. However, bundling is
*not* the right decision if a crate *is* intended to have outside
users.
> For intra-project dependencies (i.e. bevy components depending
on
> exact versions of bevy components), this is kind of expected, and we
> have tools to deal with this kind of situation (though bevy is on a
> different scale). For dependencies on third-party libraries, this is
> kind of unexpected, and I wonder why they do things like that? Locking
> some dependencies to exact versions is usually handled by relying on
> the lockfile, instead.
I was wrong about this. I actually didn't realize that the ^ was optional. I
was, um, cargo-culting that around. Ah well. Anyway, that's less of a
problem than I worried.
Will the bevy components ever be used outside of bevy? If not,
then they should be bundled. if so, they should not be bundled.
>> The packaging guidelines say that I SHOULD create patches to
update to
>> latest versions of dependencies, and that I should further convince the
>> upstream to take them. Candidly, that seems like a waste of everone's
>> time.
> This is *not* a waste of time. If we don't invest time to do that, many
> project's dependencies grow stale, and actually *increase* the need for us
> to maintain compat packages.
I have not tried this with any Rust package. My experience in the past is
that many upstreams find this the kind of thing that makes them go on long
blog rants about distro packaging -- they picked a version, it works fine,
they don't need the distraction of being told they must update it.
I heavily doubt this will be an issue with Rust. There is a reason
that dependabot is so popular.
But even when this doesn't happen, it gets into the matter of
expertise. If
I need to update a dependency for a newer-version of the sub-dependency, and
I don't know enough about either code base to do anything other than file a
"please update" bug, then everything is blocked on that.
Fair. Obviously, a patch that actually updates them to the latest
version would be awesome, but a bunch of bug reports seem to be more
of a job for a bot.
I don't dispute that helping projects keep up to the latest is
valuable
work. It even seems like it might be in-scope work for Fedora. But couldn't
we do that as something _separate_ from blocking ourselves (either literally
or through the extra overhead of compat packages) from packaging the
dependent app?
I don’t think it should be a blocker unless e.g. the out-of-date
dependency has a serious security vulnerability.
--
Sincerely,
Demi Marie Obenour (she/her/hers)