search

shssoichiro / ffmpeg-the-third

A fork of the abandoned ffmpeg-next crate which is a fork of the abandoned ffmpeg crate
Do What The F*ck You Want To Public License
64 stars 13 forks source link

sys crate needs a release, too #4

Closed mqudsi closed 1 year ago

mqudsi commented 1 year ago

ffmpeg-the-third 1.1.2 was supposed to include the static build fix, but it actually doesn't since the crate still depends on ffmpeg-sys-the-third v1.0.0+ffmpeg-5.1.2 which doesn't contain the fix.

You need to publish 1.0.1 of the ffmpeg-sys-the-third crate, yank ffmpeg-the-third 1.1.2, then release ffmpeg-the-third 1.1.3 after updating its Cargo.toml to depend on ffmpeg-sys-the-third v1.0.1.

shssoichiro commented 1 year ago

Technically the yanking and republishing doesn't need to occur because libraries do not ship with their Cargo.lock file. But yeah that's a whoops, I'll push the new version of sys, then it'll be able to be updated in av1an

mqudsi commented 1 year ago

Libraries don't ship with their lock files but if you bump the dependency in your ffmpeg-the-third Cargo.toml to depend on a non-broken version of ffmpeg-sys-the-third, that means that all a downstream crate has to do is update their Cargo.toml entry for ffmpeg-the-third to the latest version and it'll automatically require that a non-broken version of ffmpeg-sys-the-third is used. The alternative is to yank ffmpeg-sys-the-third 1.0.0 which would automatically require at least v1.0.1 (via the automatic "updating cargo index" step).

Otherwise, a downstream binary crate has to manually run cargo update (or cargo update -p ffmpeg-sys-the-third) to make sure that they are using the latest version of transitive dependencies (like ffmpeg-sys-the-third). To accomplish the same in a downstream library (non-binary) crate requires the crate author to explicitly add the fixed version of the transitive dependency to its direct dependency list so it can specify the required version number.

I've already filed a PR with av1an that updates the transitive dependency (which is how I ran into this and was motivated to fix it in the first place) so it doesn't matter to me personally if you end up changing the published dependency tree 😉