As stated before in Fedora we definitely are against this way of packaging Go, Rust or pretty much anything else. This however doesn't apply to EPEL, CentOS or RHEL, where introducing and maintaining huge amount of dependencies because of one particular package doesn't make sense. Especially if you need to drop/add dependencies when doing a simple version update as for example Go packages often do. Vendoring dependencies here definitely makes more sense at the cost of having larger packages.
I think we should establish some rules, create guidelines, add proper tooling and macros for this use cases and I would be interested in helping with that. On Thu, Sep 8, 2022 at 12:20 AM Stewart Smith via devel < devel@lists.fedoraproject.org> wrote: > Fabio Valentini <decatho...@gmail.com> writes: > > On Wed, Sep 7, 2022 at 10:53 PM Stewart Smith via devel > > <devel@lists.fedoraproject.org> 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). > > For Fedora? Probably not. If Crate Foo goes EoL (or any particular > version of it does), Fedora can easily drop/bump the package pretty > quickly. > > Possibly more relevant for EPEL though? Or may be more relevant there as > there are more Rust and Go packages coming into the dependency graph. > > For Amazon Linux? Yes, it's a concern we have. Mostly because of our > longer support life cycle for the OS and thus keeping the package set > more constant. Plus, no matter how much we say "don't depend on this", > somebody is going to, or we're not quite going to be able to wrangle all > the teams supporting the random packages that would include these > dependencies to move at roughly the same pace. > > It may also be relevant for 3rd party repositories, especially if also > building for non-Fedora distros where the build dependencies just aren't > otherwise available. > > >> 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". > > "bad case" is very much dependent on context :) . For Fedora, that's > bundling, but for Amazon Linux, we at least currently view it the other way > around, and that the bad case would be to import all the Go modules and > Rust crates as packages and ship them. > > > 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. > > Agree. > > It's probably something we (the Amazon Linux team) could/should > contribute to, seeing as it is something that's way more relevant to us > than Fedora itself. > > > 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. > > This is somewhere where the packaging guidelines for Fedora differs from > downstream distros such as Amazon Linux (and I believe also RHEL/CentOS). > > > 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 ... > > While true for packages in Fedora, for packages outside Fedora, it may > be worthwhile to have a solid opinion on tooling on a "good" way to do > this. > _______________________________________________ > 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 >
_______________________________________________ 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
