User talk:Gromit/Flutter package guidelines

Progress

Latest comment: 31 May 20231 comment1 person in discussion

Hello I wanted to create a discussion for the progress on this draft before it can be considered to be added to the list of package guidelines.

Firstly I would like gromit to review a package (I will link it later after I push it to the AUR) and then we can discuss possible improvements before possibly adding it to the list of example packaages?

It might also be worth looking into working on a Dart package guideline first before doing this, as flutter is very closely related to Dart, it would be beneficial.

Thank you,
PolarianDev (talk) 14:15, 31 May 2023 (UTC)Reply

Dependencies and sample PKGBUILD

Latest comment: 24 May 20242 comments2 people in discussion

Hello,

I just stumbled over these guidelines. Speaking as maintainer of Alpine Flutter software maintainer and AUR flutter maintainer, I'd suggest a couple of adjustments to the guidelines :

Desktop dependencies

I realized it's missing libglvnd - this is required if your PKGBUILD contains a check section executing the Flutter test framework. I'd suggest to add this.

I'd moreover to suggest to just add flutter-target-linux as proposed dependency rather than the single packages. This package is either provided by the giant aur/flutter package base or additionally e.g. by the flutter-bin packages for users who are not in mood to build Flutter themselves.

Sample PKGBUILD

A couple of issues ...

arch : Flutter by default supports x86_64 and aarch64. See the sample below.
dependencies : It's a bad idea to depend onto the entire aur/flutter package group shipping dozens of dependencies, the compiled engine for Android, skia for web, a wasm compiler and samples. The appropriate way to depend onto Flutter in a PKGBUILD is rather depending on aur/flutter-tool and aur/flutter-target-linux shipping the pure Flutter tool and the Engine as well as the build dependencies respectively.
prepare : The prepare section should rather try to execute pub with lock files enforced. Flutter config should not be executed. Desktop is enabled by default for ages. Additionally, the aur/flutter-tool package contains patches to disable analytics and version check by default.
build : We should build with the --no-pub flag.
package : We should rather use cmake to properly install the files in place. I'd as of now not suggest to install the libraries into /usr/lib since Flutter does not create versioned libraries (we could hence simply run into dependency chaos with several Flutter packages) but the cmake approach allows to correctly install all files directly to the pkgdir.
We should at least encourage users to provide a desktop file. Most Flutter applications run in gui.

Here are a couple of sample PKGBUILDs I maintain both for -git and for stable packages respecting my personal best practices.

Maybe we can find and define a good best practice PKGBUILD sample all together ?

Known issues - directory permissions

Since the recent refactor of the aur/flutter package base, this issue is deprecated. It only occurs if users e.g. use the aur/flutter-bin package or other third party packages (I'm not responsible for). Maybe we could add a hint stating under which conditions this occurs ? TheOneWithTheBraid (talk) 13:36, 24 May 2024 (UTC)Reply

Hey @TheOneWithTheBraid 👋 Thanks for your comment, I have discontinued my work on this page since quite some time, so if you want to work on it, so feel free to change it here or use it as a base for your own works! -- Gromit (talk) 13:46, 24 May 2024 (UTC)Reply