On Tue, Nov 1, 2022 at 7:07 PM Demi Marie Obenour <demiobenour@xxxxxxxxx> wrote: > > On 11/1/22 10:40, Matthew Miller wrote: > > On Wed, Oct 19, 2022 at 01:04:39PM +0200, Fabio Valentini wrote: > >> For intra-project dependencies (i.e. bevy components depending on > >> exact versions of bevy components), this is kind of expected, and we > >> have tools to deal with this kind of situation (though bevy is on a > >> different scale). For dependencies on third-party libraries, this is > >> kind of unexpected, and I wonder why they do things like that? Locking > >> some dependencies to exact versions is usually handled by relying on > >> the lockfile, instead. > > > > I was wrong about this. I actually didn't realize that the ^ was optional. I > > was, um, cargo-culting that around. Ah well. Anyway, that's less of a > > problem than I worried. > > Will the bevy components ever be used outside of bevy? If not, > then they should be bundled. if so, they should not be bundled. Yeah, this is something that I hope to be able to improve soon. > >>> The packaging guidelines say that I SHOULD create patches to update to > >>> latest versions of dependencies, and that I should further convince the > >>> upstream to take them. Candidly, that seems like a waste of everone's > >>> time. > >> This is *not* a waste of time. If we don't invest time to do that, many > >> project's dependencies grow stale, and actually *increase* the need for us > >> to maintain compat packages. > > > > 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. > > I heavily doubt this will be an issue with Rust. There is a reason > that dependabot is so popular. Exactly. I forgot to reply to this in my previous post, but many Rust projects on GitHub use dependabot (or similar bots) to automatically bump their dependencies to the latest version. The projects that *don'*t do that are the odd ones out, but still, PRs submitted to these projects are usually received positively. (snip) > > 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? > > I don’t think it should be a blocker unless e.g. the out-of-date > dependency has a serious security vulnerability. Yeah, I tend to be rather pragmatic in this regard. Patch and submit to upstream if it's easy, keep a compat for the older version around if it's not. The only exception to this rule I recently made was to retire some outdated versions of HTTP libraries, which were only used by obsolete packages anyway. 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
