On Tue, Nov 1, 2022 at 3:40 PM Matthew Miller <mat...@fedoraproject.org> 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. > > > [...] > > 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?
That won't do. It would mean that we end up having to review and keep track of *more* crates instead of fewer. > > 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. Of course. People who manager to package their favourite Rust app without problems don't come to complain, do they? > > 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. > > Okay, I'm open to that. I'll have more time to spend on this soon, I hope, so I'll try to come back with a prototype ASAP. > > 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...) It's probably a misconception that the Rust standard library is small. It's not small, it's just not not very *broad*. And there's some libraries that are also quite "batteries included", for example, hyper and tokio, which could be considered "standard" at this point. (snip) > 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. > > 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. It's not, though. This is what SIGs are for. I explicitly tell people who are new to Rust packaging that I'll help them get their dependencies reviewed and keep them up-to-date so they can focus on their own stuff. That some people don't accept help when it is offered is a different problem ... > 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? > > > > The guidelines provide for creating compat packages, but that means 1) the > > > existing shared work is less useful, 2) requires even more extra steps, > > > and > > > 3) even without reviews for compat has extra administrative overhead. > > > > We only maintain compat packages where porting to the new version (and > > submitting the changes upstream) is not feasible. Again, isn't that > > how Fedora is supposed to work? > > I guess it depends on how broadly one reads "feasible". :) Many "ports" to new versions require only changing names of structs / methods, import paths, or even only bumping the dependency. I'd say that's pretty easy, particularly if upstream projects publish good Release notes. > > The barrier for participation is too high in some cases, I agree. > > However, in my experience, that's for a different reason: > > > > The "shiny new things that happen to be written in Rust" that new > > contributors want to have in Fedora are often very complicated > > projects that even experienced Rust packagers would need to spend a > > lot of time on. > > > > Examples of that might be: > > - wasmtime: I ultimately abandoned the attempt to package it "because > > Fedora Legal", but the packages themselves worked fine > > An aside, but: did I miss something with this on the Legal list? The only > thing I'm finding is a question about how to phrase `Apache-2.0 WITH > LLVM-exception`. You might remember the fedora-council ticket tagged "OMG Urgent!!!1": https://pagure.io/Fedora-Council/tickets/issue/408 It was closed, but I still haven't received any actionable information from Fedora Legal to this day. > > - deno: requires dozens of new packages, some of which also have > > unclear / questionable licenses as well, but the packages themselves > > worked > > I'm not sure this example isn't agreeing with me. :) How so? Even if packaged from bundled dependencies, the unclear status of some components would have blocked the package from being added to Fedora. > > On the other hand, many "nice" CLI tools that people want to package > > often require minimal knowledge of Rust packaging (our tools are > > pretty nice for "standard" projects), and often only need very few new > > dependencies to be packaged. > > > > Just as an example, I just today started reviewing a "simple" Rust > > application here: > > https://bugzilla.redhat.com/show_bug.cgi?id=1990713 > > > > The spec file is very simple and almost entirely automatically > > generated (with the exception of the missing License breakdown for the > > statically linked binary), no dependencies were missing from Fedora. > > Even Rust newbies would not have trouble packaging this, and that > > would be a way better entry point than packaging stuff like Bevy. > > How many lines of that are unique to that package. Few. Most of it is boilerplate. You don't *need* to understand what's automatically generated, you only need to know what you're doing if you manually change things. That's the whole point of having a spec file generator. > I guess my impression of this is a little big colored by a Python packaging > adventure from a little bit ago: > https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/MDYIFGPZS775FKXZU3LZPAJYJ36HGIDH/#WFH5G43DC2GMNLAJ2MSTXFZEROWCSYLZ > ... where it kind of turns out that what looks like it could be automated > ends up with a hand-tuned specfile with a lot of exceptions. > > I'm hopeful that maybe the Rust version of this could be more streamlined. It already is. > What if, instead of the specfile + boilerplate, there was a toml (or yaml, > or whatever) file that just listed whatever is unique to the package? > > For this package, maybe it is... nothing? Just need an indicator that this > is a Rust package. That's basically already the case for many packages. We have rust2rpm.conf files committed into dist-git which control some aspects of spec file generation, making many manual edits unnecessary. > I know it looks simple to an experienced packager, but that specfile has a > _lot_ of complicated domain knowledge -- both general Fedora RPM packaging > and the rust packaging macros. And you don't really need to understand most of these things, unless the upstream project is doing something weird, and you need to adapt the packaging to that. > > > And, I led with: I appreciate all the work you've all done to make this > > > work. That's definitely true — I think it was super-valuable to pilot this > > > approach. But I think that the Rust ecosystem would be a great place to > > > pilot a different way. Something lightweight where we cache crates and use > > > them _directly_ in the build process for _application_ RPMs. > > > > We have talked about this multiple times, but it won't work. > > I think this was tried with first-class maven artifact support in > > koji, but we all know how the Java packaging fiasco ended. > > I would rather see it as: we learned some lessons from that approach and can > do it better. So would Red Hat be willing to invest more resources into CPE to implement this for Fedora infra? > > Or even if making Rust crates first-class deliverables *did work*, it > > wouldn't give us the benefits of the current approach: > > - we ensure that all crates in Fedora *build* on all architectures > > - we ensure that most crates in Fedora pass their test suites on all > > architectures > > But those things aren't attached to making them into RPMs. Even if they're not - this is how they are already implemented, and they already work. Changing things to a completely different paradigm would require a massive amount of work just to get back to the state *we already have*. I won't waste my time on that, sorry. > > - we check all crates for objectionable content, licensing problems, etc. > > Nor is this. And I don't think we _should_ skip this part. It is clear > value. > > > > - we change build flags to default to dynamically linking to system > > libraries instead of statically linking against vendored copies > > This too. > > Mostly, at least. Assuming this isn't _prebuilt binaries_ or similar, > upstream may or may not have a good reason or strong opinion. Like any > bundling, we need a system which can track and react to security problems > with those libraries, though. (And we don't meaningfully have that for RPMs > now either.) There are no prebuilt binaries in the Rust stack. And there's only very few cases where we don't dynamically link against system libraries, but statically link bundled libraries. libgit2 is one of them, where the package in Fedora is chronically under-maintained and out-of-date (and hence too old for what we need in the Rust stack). > > This would mean that we basically stop contributing things to the > > upstream Rust ecosystem: > > - we diagnose / report / fix architecture support issues > > - we port projects to new versions of dependencies > > - etc. > > Why? I think it would give us _more_ time to do those things. Would it? So you suggest that in addition to working out a new delivery mechanism for Rust crates, we *also* devise a new way to build and test them? > > I see this work in the upstream ecosystem as an important part of the > > work we do in packaging Rust crates for Fedora, > > and I would not want to endorse an approach that meant we no longer do > > these things. > > > Sure! > > > > Rust packages include a lot of machine-readable metadata. We should be > > > able to watch for CVEs, RustSec, and other security notices even without > > > encoding the metadata in RPMs. License review could also be automated — > > > the field in Cargo.toml is supposed to be SPDX, so that's convenient. > > > [3] > > > > I already monitor RustSec advisories and check *all of them* against > > Fedora packages. This takes up a miniscule amount of the time I spend > > on Rust packaging (because there's so few Rust security advisories). > > If I remember correctly, there were only 2-3 CVE issues in the Rust > > stack that actually affected our packages, and dealing with those was > > very simple: > > 1) Push the patched version of the library, 2) rebuild dependent > > applications, 3) submit to bodhi. > > There's some amount of automation that *could* be done (mostly in > > figuring out which applications need to be rebuilt for a given library > > change), but that's also pretty easily done with a "dnf repoquery" or > > two. > > I appreciate that you do this (very much!). But it seems like this could be > _entirely_ automated (with alerts for dependency or license changes, etc). It could be, but it's not high priority for me, just because it's such a small amount of time I spend on that compared to other things. (snip) > > If manual changes *are* required, then these changes would also be > > required in the "first-class crate artifact" scenario, so you don't > > gain anything. > > And if there's other problems that are caught during package review, > > the distribution mechanism doesn't matter, either. > > But our mechanism is really complicated -- a barrier to entry, lots of > places for mistakes, and even with collaboration with other distros, very > Fedora-specific. So I think there is something to gain. No. :) > > In my experience, changing the distribution mechanism or packaging > > paradigm will often make things *worse* instead of better. For > > example, the implosion of the NodeJS package ecosystem in Fedora was > > not only caused by the horrid state NPM, but also because the new > > packaging guidelines which prefer bundling essentially made it > > impossible for packagers to verify that objectionable content is > > present in vendored dependencies. For Java, Modularity was seen as a > > "solution", but the result was that basically everybody - except for > > the Red Hat maintainers who maintained the modules - just stopped > > doing Java packaging because of the hostile environment. > > I really hope we can look at these and learn how to do it better, instead of > deciding that better isn't possible. And — while I'm not really up on node — > I have pretty good hindsight on what went wrong with modularity. (Not enough > to try modularity _again_ just yet... but that's a different thing. A whole > talk for next year's Nest/Flock, maybe....) Please, no. It's time to stop beating that dead horse ... Fabio _______________________________________________ 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
