On Wed, Nov 30, 2022 at 8:16 AM Fabio Valentini <decathorpe@xxxxxxxxx> wrote: > > On Wed, Nov 30, 2022 at 12:54 PM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: > > > > > This is true, and probably also not "fixable". We need to make some > > > amount of non-upstreamable patches to some crates (most notably, > > > removing Windows- or mac OS-specific dependencies, because we don't > > > want to package those), but in some cases, these are "incompatible" > > > changes, and Rust *developers* should not be targeting our downstream > > > sources that have these differences with actual upstream sources. > > > > Yet you say above "We *do* provide value to both users *and* > > developers" yet you say developers shouldn't be targeting that work? > > We provide value to developers by basically running a huge free CI > across a wide range of architectures. > > That doesn't mean that they should develop against crate sources we > have in Fedora, similarly to how upstream Python developers probably > should use pip/venv instead of "whatver is in Fedora". The same > applies to basically every language ecosystem except C/C++, where the > package manager story is just so bad that system libraries are > actually the only reliable development environment. > > > > 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. > > > > And that ends up being quite a bit of work from my point of view. Also > > the way the packaging works with options things like devel or optional > > features ends up being very painful. I will often drop out optional > > features just so I can do less packaging. > > Recent versions of rust2rpm automatically generate a patch to remove > non-linux dependencies, so that work has effectively been reduced to > zero. > Disabling unused optional dependencies can also be done with either a > rust2rpm config option or with a simple patch, so that should not be a > problem, either. I also don't understand why disabling some optional > features is such a bad thing? I don't think we have a policy in Fedora > that says we *must* enable *all possible functionality and optional > features*. > > > > > We're doing okay with #1, but... I think #3 _even_ with all of the work in > > > > Rust-to-RPM packaging isn't sufficient. I've played with the Bevy game > > > > engine and will probably have a few things it would be nice to package to > > > > make available in Fedora Linux. I might not even mind maintaining Bevy > > > > itself. > > > > > > Somebody actually already started packaging Bevy components - some > > > packages are already approved and some are still pending review. Not > > > sure what the progress has been there, but it's not *impossible*. > > > > Well nothing is *impossible* if you have enough stamina, resources or > > whatever else. I don't find saying something isn't *impossible* > > necessarily makes it compelling. > > I agree. And I think we can do better, as I said in my original post. > > > > > But running `cargo fetch` with a clean cache pulls down *390* crates. Of > > > > these, it looks like 199 (!) are already packaged as rust-[crate]-devel, > > > > which is *amazing*. But... that still is hundreds that I'd have to add. And > > > > mostly they are things I don't know _anything_ about. > > > > > > 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. > > > > In my experience, and I'm not packaging any form of gaming engine, > > it's not an extreme case, for a few small things and one slightly > > larger thing I *have* packaged I now maintain over 60 more packages. I > > have another one I want to package and AFAICT I get to package another > > 50-100 but frankly it's hard to tell, and this is something I have > > control over and have been actively trying to do upstream reduction of > > deps. > > As far as I know, salimma's intern worked on a tool to determine > missing dependencies for Rust projects in Fedora recursively, which > should make it easier to determine the exact set of things that you > would need to do here. > > > And requests to make things like this easier have been open for over a year: > > https://pagure.io/fedora-rust/rust2rpm/issue/140 > > Right. I'm sorry about the issue reports that have been open for a long time. > > rust2rpm / rust-packaging is an entirely community-run project. We > don't get any support from Red Hat (or other places) for anything > except the Rust compiler itself. And with the original developer of > rust2rpm (Igor) being gone, nobody who understands the low-level stuff > in there is still around. > zbyszek and I are trying our best to keep things running, but at this > point, we'll need basically a rewrite of both rust2rpm and the RPM > dependency / provides generators to support new cargo features. And > since I don't have much time for that right now (busy finishing my > university degree), these things are still pending. > I'm still around, but my interest in Rust has flagged significantly after getting crap from upstream Rust developers and many other folks in the Rust community when Igor and I did this work. I do still look over PRs occasionally too. > > > Bevy is a bit special, because it (presumably) pulls in lots of GPU / > > > OpenGL / Vulkan related libraries, which we didn't need to package for > > > anything else yet, and it's also split into dozens of small libraries > > > itself, which can be painful to package, that is true. > > > > > > We might need to reconsider how to package projects like this. I'm > > > pretty sure we could find a way to package them in a way that's > > > compatible with how we're currently doing things but would be much > > > less busywork. > > > > Well if we're finding a solution for those sorts of projects we should > > be doing it for all rust projects. A lot of projects have internal > > virtual/workspace bits where they split up things up internally but > > may have a dozen or sub projects. These make absolutely no sense to > > split up into separate packages because they're all bundled together, > > have to be bumped together yet as it standard at the moment you either > > have to package them all separately or do nasty rpm spec hacking to > > try and glue it into a single rpm. Again RFEs to make less busy work > > have sat for well over a year, some even 3 years, with no progress: > > > > https://pagure.io/fedora-rust/rust2rpm/issue/141 > > Same here. I *would like to work on this and improve the situation for > all of us (including me)*, but I just don't have the time to do that > right now. > > > > 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? > > > > I think the big difference here from my experience, and I've packaged > > right across the Fedora spectrum, is that most of the python style > > projects are able to use a pretty comprehensive standard library and > > crypto library which helps minimise a lot of the extras I've seen in > > the rust ecosystem. > > The Rust standard library is intentionally narrow. I don't think that > will change any time soon, so we'll have to deal with it. Either way, > it looks like the ecosystem is starting to standardize around a few > common libraries (serde for de/serialization, tokio as async runtime, > hyper for HTTP clients + servers, etc.), so things might get less > sprawling in these areas. > I think a de-facto standard library will emerge over time. Rust is young and most of its developers don't know what they want from the language ecosystem yet. It'll take time to sort it out. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
