On Sat, Apr 6, 2024 at 4:45 AM Scott Schmit <i.grok@xxxxxxxxxxx> wrote: > > This perhaps explains why my efforts to use these packages did nothing > but waste my time for days. 😡 > > It sounds like you've wasted others' time as well. That's not very > Friendly, and playing nitpicky language lawyer games doesn't change > that, and is also unFriendly. This is about more than just you. Other > people are trying to do things, and you're sitting here saying "too bad, > I don't care, it doesn't work and that's not my problem." If that's not > your intent, that's how it's coming across. > > That's an unacceptable attitude, and I think you need to rethink how > you're approaching this conversation and re-read > https://docs.fedoraproject.org/en-US/project/ from top to bottom. I'm sorry about that. I don't want anybody to feel like they're wasting their time. I really am trying to do my best here, but there are some constraints that I need to work within - both from the upstream cargo side and the RPM packaging reality. I inherited the way we do Rust packaging from my "predecessor" when he stopped contributing to Fedora, I didn't invent things this way. Since I took over maintenance of most Rust packages in Fedora (and the tooling we use to create and maintain them), I tried to push many improvements that make things better for package maintainers. However, we're working with an upstream project that is either indifferent or entirely hostile towards distribution packaging (rust / cargo). Almost all improvements and / or bug fixes that we have asked for in the past years have been either ignored or dismissed as "not our problem". As frustrating as this is, I need to work with what I have, and sometimes that leads to less than ideal outcomes - but please don't blame me for that. > It does not clearly state *anything* you've just now dropped on us. > Also, all RPMs are packages, not all packages are RPMs. For all I know, > "package" could be another way of saying "crate." And just because it's > "intended" to do something doesn't mean "it won't work for anything > else" or "it's not supported if you try to use it for anything else." You are right, this could be stated more clearly. > And I question whether making packages like that is acceptable for > Fedora. The way Rust packages work (and Go packages work very similarly) was signed-off on by FESCo and / or the Packaging Committee, multiple times. If you have a problem with how things work, take things up with those decision bodies. Again, I'm trying to make something that works well here, but I'm trying to do my best given the constraints that we're working within. > The naming convention for packages for the last 25 years as far as I've > ever known has established that "foo-devel" packages provide programming > support files that will allow *me* to build *my own* software using > conventional build tools. > > The way you've described it, they shouldn't be "foo-devel" packages at > all, because they're useless for routine development. Admittedly, the > packaging guidelines don't address this, but I assume this is because > this principle is so obvious that nobody thought it needed to be said. > I mean, it's in the mission statement! The distinction between "-libs" and "-devel" subpackages doesn't really make sense for languages like Rust or Go. There *are* no separately distributed header / development files. The source code *is* the thing that is redistributed for development. I'm not sure if there's a better name for them than "-devel" packages. > It seems to me that these not-"devel" packages should be named > "foo-mock-build-support-for-internal-use-only-and-you-are-on-your-own-if-you-try-to-use-it-for-anything-else". > That would be a whole lot clearer. We can even consider the > ridiculously-long name a feature. Sorry, but this isn't helpful. > You've already said there's no support for using them, so it sounds to > me like they're ineligible for inclusion in RHEL (which involves paid > support), so who cares if it works well in RHEL? You've already said > they don't work well in Fedora either. We support these packages *for building other packages*. The Rust stack is one of the most well-maintained large language stacks in Fedora, with consistently very low numbers of packages that have issues like broken builds or broken dependencies. But RHEL does not include packages for Rust crates *at all* and uses vendored dependencies unconditionally. Which is not an acceptable solution for Fedora for multiple reasons. > > 1. We don't want Rust applications to vendor their dependencies > > I'm trying to write my own software, so what business do you have > telling me what I can do with it? Where's my Freedom? Insert the > Fedora mission statement here (again). ??? I really don't understand what you want to say here. The Fedora rule against bundling packages' dependencies whenever possible has been there for decades (predating Rust as a language). You can do with the software as you please, but for packaging things for Fedora, there are some rules and guidelines that need to be followed. > > 2. Rust can only do static linking (for now) > > -> Dependencies can only be shipped as source code, not as compiled artifacts. > > > > And while you *can* use packaged Rust crates for local development if > > you really want, it's not really a supported use case. > > It might also help if you put your restrictive terms of service into the > description explicitly instead of expecting everyone to be mind readers. > > Is this documented somewhere besides your email? Yes, Rust packages were granted an exception for the Updates Policy by FESCo that includes this language: | This exception covers all Rust -devel packages, i.e. rpms with Rust sources. | Those packages are used to build packaged Rust binaries and are not directly usable by users. see https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/#rust > Maybe you could link to that documentation (which hopefully also > explains how to use these packages as end-users, in line with the > mission statement) from the RPM descriptions. > > All that said, I'd appreciate it if we could please circle back to the > original concerns and approach them more productively. I can *try* to make things work better, but that doesn't mean that I can make the *impossible* possible. 1. Adding "--allow-dirty" to the "cargo package" command run in "%cargo_install" would remove *one* issue (out of multiple ones) with building Rust packages with "fedpkg local". It looks like an issue asking for an enhancement for "fedpkg" to make this unnecessary has been open (and unaddressed) since 2018: https://pagure.io/fedpkg/issue/291 I'm not sure if "fedpkg local" could be enhanced to directly support dynamically generated BuildRequires, though, so any packages that use this feature will not work OOTB with "fedpkg local" (this includes Rust, Python, other language stacks that use modern RPM features). I opened a ticket about this: https://pagure.io/fedpkg/issue/545 2. Making Rust "-devel" packages more useful for general "development" tasks would require some work (and additional ongoing maintenance burden). For example, Rust crates' feature flags (which are mapped to RPM packages for dependency resolution) change frequently with new upstream versions. We would need to maintain a list of removed subpackages (corresponding to removed feature flags) that need to be "Obsoleted" by the main "-devel" subpackage in order to preserve the upgrade path for users who install those packages in non-ephemeral systems. Keeping track of this would introduce a significant additional maintenance burden. If using Rust crates that are packaged for Fedora for local development is indeed a use case that we need / want to support, then it would be possible, but until now there has been no to little demand. (When asked, I have previously always discouraged usage of packaged Rust crates for actual "offline" development purposes. Similarly to packages for other languages' packages, our packages for Rust crates have downstream patches that might make them an unsuitable target for developers.) Fabio -- _______________________________________________ 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
