Arch Linux User Repository

TL;DR

Upgrade using aur/yay might take very long and works inefficiently.

Upgrade using aur/paru requires the -d flag.

This is not my fault.

Note to the lovers of AUR helpers : It looks like dependency resolution is a complex topic. Despite all package relations being properly declared in the Flutter packages, most AUR helpers seem to have trouble resolving the dependency chain between the package bases aur/flutter and aur/flutter-artifacts-google-bin. This is not my fault and I cannot do anything about it.

It looks like the initial installation works fine using aur/paru. Sadly aur/paru does not reach at building updates for the package without additional flags. Please use paru -Syud (whereas the -d is the relevant flag) to upgrade the package.

On the other hand aur/yay properly reaches at both installing and updating this package, even though it builds the package 15 times (!!!) again and again.

If you use aur/paru, consider to simply execute pacman -R flutter && pacman -Rns flutter to clean up the previous installation of both package bases.

• https://github.com/Jguer/yay/issues/2413
• https://github.com/Morganamilo/paru/issues/1173

If you build both package bases using makepkg -sfC and later on install all build outputs using pacman -U, both the installation and the updates work like a charm.

I'm very sorry for the inconvenience, but sadly there's nothing I can do about this.

Huge update to the Flutter AUR package :

The previous implementation basically did a user installation of Flutter - downloaded the custom Dart SDK, CI artifacts from Chromium CI and had to be kept in user R/W access in order to have the Flutter Cache Manager working.

These times are now over - a clean and (almost) completely rewritten PKGBUILD which now uses clean dependency declarations, system Dart and Gradle and for sure no more user R/W installation directory.

This AUR entry is now a split package. Installing aur/flutter will still bundle the entire toolchain you knew from before. The other way round, if you don't need everything - e.g. when depending on Flutter as a build dependency in another package, you can choose to only depend on what you need.

The following split packages are available :

• flutter : meta package containing all other split packages

• flutter-common : the common files for Flutter needed for all use cases

• flutter-devel : your option of choice as a developer - ships the Flutter tool and all required templates to e.g. create a new project

• flutter-tool : The pure Flutter tool. Use as depends to build your package.

• flutter-target-linux : The Flutter Linux build files. Use as depends to build your package.

• flutter-target-web : The Flutter web build files. Use as depends to build web apps (e.g. fluffychat-web does this).

• flutter-target-android : The Flutter Android build files. Use if you want to develop Android apps.

• flutter-gradle : The Flutter Gradle wrapper. Populated from system Gradle.

• flutter-intellij-patch : a tiny patch to make the IntelliJ Flutter plugin work with the new package.

• flutter-material-fonts-google-bin : Mandatory fonts package, planned to have a system-installed drop-in replacement soon.

• flutter-engine-common-google-bin : Shared part of the Flutter engine - downloaded from Google servers.

• flutter-sky-engine-google-bin : Flutter sky engine - downloaded from Google servers.

• flutter-engine-linux-google-bin : Linux part of the Flutter engine - downloaded from Google servers.

• flutter-engine-web-google-bin : Web part of the Flutter engine - downloaded from Google servers.

• flutter-engine-android-google-bin : Android part of the Flutter engine - downloaded from Google servers.

• flutter-gradle-google-bin : The Flutter Gradle wrapper - downloaded from Google servers.

• flutter-dart-google-bin : The Flutter original Dart SDK - downloaded from Google servers. This is helpful if the extra/dart package is not available in the right version on your distro or remix.

Stay tuned for non google-bin versions of the engine, they are in coming !

Since almost everything is written from scratch and heavy patches are applied to use the system packages as dependencies, there might still be bugs occurring. Please report them otherwise I can't fix them !

Hello,

I have not really done much since I was added as a co-maintainer, I expected to fix the package, but due to issues with google, the likelihood of a working flutter package is low, and would require many patches.

I currently do not have the time for this, but I do want to try to help out, I apologise to the other maintainers but you continuing to aimlessly bump this package is not going to work.

I am aware that flutter contributors and developers are reading these posts, I kindly ask you to reconsider rejecting your decision to not help with packaging flutter, you have the better knowledge of the codebase and it would help out a ton, patching flutter would be a massive task and would be difficult to pull off.

Those who are complaining about the package being update, the new version overwrote the old version, thus this package can not be bumped until the new new version is released, please read the comment history.

I would appreciate if the other maintainers please reach out to me on IRC so we can better discuss this, I am within #archlinux-aur and my nick is the same (Polarian), please reach out so we can discuss this situation.

I have emailed you both in the past, but I never received a response, which is a severe disappointment, my email is polarian@polarian.dev, if you missed the email you can search for it.

Without communication this mess will never be solved, so please come out of the corner and reach out and we can discuss this problem in more depth.

Thank you all for helping out, especially the flutter developers which have helped users out in the comments. That you to the two maintainers who kept this up to date and tried to package flutter in its current state, but unfortunately it is not going to work (due to flutter needing read and write permissions to its own directory.

Flutter devs, would be appreciated if you could find the time to join #archlinux-aur. Maybe form a channel to fix this package, who knows.

Take care all,
Polarian

I've published a flutter-engine and flutter-engine-google-bin package. The former compile the flutter engine from source. This will take a lot of ram and time depending on your machine and if you compile everything into ram. Install the later if you want to use the pre-compiled binaries from google. See my localsend package for an example on how to use. These are only makedepends, apps will have all they need to run.

Package is already flagged. Just wait a couple weeks for update. If still not updated by then, open an orphan request.

If impatient, update a local copy of the PKGBUILD.

So I assume you are asking to wait until flutter-3.13.4 gets released, because of the overwrite of 3.13.3?

The upstream release is out. If you mean on AUR, you can submit a PR to update it.

@patlefort this is unconventional, pulling about 500MB (about 1GB when decompressed) runtime each time you want to update the package is so inefficient.

Furthermore, we should always strive for repro and having dependencies managed by Arch, not by upstream binaries.

I don't care if it takes 100 patches, and 2 years to get it working, I am not going to give up and just pull a binary from google.

You can't build trust if we simply pull binaries from google without building them ourselves. As a note this should be flutter-bin not flutter!

I said python-flet but actually I meant localsend as an example.

@dvalter See comment https://aur.archlinux.org/packages/flutter#comment-933929

Checksum for 3.13.3 tarball does not match, for me it currently is 4fc057286135d4b7559db7d735a235753e273f284219b2e9d2f77aa455dd923e

It might be better to add the flutter repo in the sources of the package that needs it instead of depending on this package. You can select the exact version that you need, check localsend for an example. Of course since it's pretty big it should be cached by the user.

@cfujino As per usual, flutter releases a new version so now I can not build packages with the old version I have on my repository.

Now instead of error code 66 I get error code 4, do I even need to ask whether this is magically fixed if I update to the new version?

Maintaining a flutter package seems more pain than it is worth, and as flutter developers have ruled they are not going to help out, nobody seems to want to package flutter applications anymore, I wonder why?

So I assume you are asking to wait until flutter-3.13.4 gets released, because of the overwrite of 3.13.3?

Until then nobody can build flutter packages on Arch Linux it seems!