On Wed, Sep 7, 2022 at 10:53 PM Stewart Smith via devel <devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote: > > For Amazon Linux, we take a different approach to Fedora (but similar to > RHEL) for software written in Rust and Go, and instead bundle > dependencies rather than have each module/crate in its own RPM. We do it > so we don't have to synchronize moving dependencies, or making these > libraries/packages part of what customers could take a dependency on. Is this really a concern? Because of the way Rust packages are built, they are essentially useless for any other purpose than serving as dependencies for other Rust package builds. And because they are only ever installed in temporary build environments (i.e. mock chroots), we don't need to care about either the Updates policy (approved exception by FESCo) and upgrade path (nobody should install those packages on non-ephemeral systems). > Somewhere on my TODO list (or a TODO to delegate to someone) is to do > that automatically from some packaging helper macros, but currently > it's just way too manual and annoying. > > It'd be interesting to know what the general Fedora feeling is about > having a distro/package level choice on this and a bunch of > macros/scripts that help with that for packagers. The choice is basically already there, there's just no standardized tooling for the "bad case". For packages where not using the bundled dependencies is not possible, it is already allowed to do so. Having better (and consistent) tooling support for this case would be great, though, and if somebody can contribute that, even better. But for packages where it *is* reasonably possible to build without vendored dependencies, they also MUST NOT be built that way. This is not a rule that's specific to Rust (or Go), but is a general rule for Fedora packages. In this case, providing better tooling for building with vendored dependencies would make it easier for packagers to be "lazy" and not do "the right thing" rather than follow our rules, which is one of the reasons why tooling isn't there yet ... 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
