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) _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org 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/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
