Flutter packages that rely on external binaries make package shutdown a breeze

[stephane-archer]

ffmpeg_kit_flutter is a discontinued package but it also rely on external binaries that have been deleted by it maintainer.
That means pub.dev packages rely on external binaries that could be removed at any moment.
That means most users of this package could not build their app anymore.
I didn't expected this kind of package shutdown possible on pub.dev, from the documentation I understood that new users could not use the package but that existing users could.

[isoos]

@stephane-archer: Could you please provide more details on what external binary the package used and how it is missing?

[stephane-archer]

[!] Error installing ffmpeg-kit-ios-https
[!] /usr/bin/curl -f -L -o /var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/d20250407-4410-rhuhse/file.zip https://github.com/arthenica/ffmpeg-kit/releases/download/v6.0/ffmpeg-kit-https-6.0-ios-xcframework.zip --create-dirs --netrc-optional --retry 2 -A 'CocoaPods/1.14.3 cocoapods-downloader/2.1'

You can easily add ffmpeg_kit_flutter to your dependencies to see the issue https://pub.dev/packages/ffmpeg_kit_flutter

[stephane-archer]

https://github.com/arthenica/ffmpeg-kit/releases/download/v6.0/ffmpeg-kit-https-6.0-ios-xcframework.zip has been removed from GitHub, and now any users of the package can't use it.

[isoos]

This seems to be a very unfortunate case, where the author decided not only to abandon the project, but also remove the built binaries from hosting repositories. https://github.com/arthenica/ffmpeg-kit links to https://tanersener.medium.com/saying-goodbye-to-ffmpegkit-33ae939767e1 and they describe that the removal of the built binaries was on the suggestion of a law firm. I don't see malice or fraudulent intent from the author.

The package is marked discontinued on pub.dev, I don't see any immediate action one can take for cases like this.

However, this may be a good example to consider if/when planning for supporting built native binaries on pub.dev. /cc @jonasfj @sigurdm

[sigurdm]

Yeah - in general we cannot prevent packages from interacting with the outside world. But I see some value in allowing packages be consume binaries published on pub.dev, such that they will continue working as long as pub.dev serves.

But we currently don't have any infrastructure for that (besides embedding the binaries inside the package archive itself) And it is probably a not a trivial task to design build something like that.

cc @dcharkes

[dcharkes]

But we currently don't have any infrastructure for that (besides embedding the binaries inside the package archive itself) And it is probably a not a trivial task to design build something like that.

Tracked in:

• Native assets on pub pub#3693

[stephane-archer]

I don't see malice or fraudulent intent from the author.

Me too

It's just that I expected the package on pub.dev to not rely on external things that could be easily taken down.
It would be better if the packages on pub.dev relied on just pub.dev to be running. Github can break links, and hosting services come and go.

Today, any dependencies on pub.dev are possibly a time bomb because of a URL breaking.

[sigurdm]

It's just that I expected the package on pub.dev to not rely on external things that could be easily taken down.

Yeah - ideally that would be how things work. I think we want to work towards that world, but cannot provide a timeline.

Closing as a duplicate of dart-lang/pub#3693