Removing bundled LilyPond unstable binary?

[fedelibre]

Rephrasing this issue to make clear that the stable LilyPond must be bundled and only the development version might be removed in the future.

For a while I've been thinking of the idea of removing the LilyPond binaries the unstable LilyPond binary bundled in the flatpak app. The advantages would be:

• Speed up the build of Frescobaldi flatpak. Not much relevant
• Simplify the maintenance of the manifest. LilyPond unstable versions are automatically updated since March 2024.
• Use the official binaries, optimized by LilyPond developers. (Next LilyPond stable - 2.24 - will be released as a static binary which can be run indipendently from any directory; that is, no installers)

Reasons to keep the unstable bundle:

• LilyPond binaries do not include an aarch64 binary. Even if aarch64 users are a tiny percentage of Flathub users, I don't want to lose them. See this discussion: basically, we need a native build host to build for this architecture. @hahnjo does Gitlab have a aarch64 machine?

• I like the idea that Frescobaldi flatpak is ready to go as soon as you install it (as regular DEB or RPM packages do). Without the bundle, users will have to download the binaries or the application will be useless. I hope that Frescobaldi could implement an automatic download of LilyPond binaries at startup, see Frescobaldi issue 1429.

[hfiguiere]

1. Speed up the build of Frescobaldi flatpak.

This argument is irrelevant.

[jeanas]

@hahnjo does Gitlab have a aarch64 machine?

I don't see anything like that on https://docs.gitlab.com/ee/ci/runners/saas/linux_saas_runner.html

I like the idea that Frescobaldi flatpak is ready to go as soon as you install it (as regular DEB or RPM packages do).

I do too.

[hahnjo]

@hahnjo does Gitlab have a aarch64 machine?

This is also not really the relevant question because the current procedure is that I build the binaries "locally", in VMs or via SSH to MacStadium. So what I would need is direct access to an AArch64 machine, or somebody has to invest the effort of automating the binary creation (which I'm not even sure I'm a fan of, as I said in prior discussions). Combined with the relatively low demand, I don't think this will happen for 2.24

[jeanas]

I think there are two options being conflated in this issue: not bundling LilyPond at all and letting Frescobaldi auto-install it (soon to become possible), or bundling the latest stable and possibly unstable LilyPond but use the official binaries instead of building LilyPond from source in the Flatpak manifest. @fedelibre Your reason (2) for not changing the current setup doesn't apply if we just use the official LilyPond binaries.

For my part, I'm very much in favor of doing either one, because it will simplify maintenance as you said, and because building LilyPond in the Flatpak is duplicate effort in a sense.

(BTW, I don't think build speed is irrelevant — right now, each build of the Flatpak takes >1 hour, which makes it relatively painful to test changes. I'm willing to bet most of the time can be attributed to Guile, which is glacial to build because of all the byte compilation bootstrapping.)

I'm relatively indifferent as to whether we should include LilyPond preinstalled or not. I think a good compromise could be to include the latest stable version but not the latest unstable version, and let people auto-install the latter through Frescobaldi if they want to. That way, we're close to getting the better of both worlds: make the Flatpak immediately usable, but also obviate the update of LilyPond each time a new development version is released, which is much more frequent than stable releases.

[jeanas]

Regarding arm64, I'm indeed not sure many people would need it... I guess they can also use a distro — I would expect someone using Linux on arm64 to be technically savvier than an average Ubuntu user, but maybe I'm wrong. Are there download stats of x86-64 vs. arm64 for the Frescobaldi Flatpak?

[fedelibre]

I'm relatively indifferent as to whether we should include LilyPond preinstalled or not. I think a good compromise could be to include the latest stable version but not the latest unstable version, and let people auto-install the latter through Frescobaldi if they want to. That way, we're close to getting the better of both worlds: make the Flatpak immediately usable, but also obviate the update of LilyPond each time a new development version is released, which is much more frequent than stable releases.

I totally agree with this approach!

I want to keep the bundled stable LilyPond for a number of reasons, but I'm very happy to not build the latest unstable.
I think that the average user is quite annoyed of the frequent updates to get an unstable release he/she probably won't use.

[fedelibre]

Regarding arm64, I'm indeed not sure many people would need it... I guess they can also use a distro — I would expect someone using Linux on arm64 to be technically savvier than an average Ubuntu user, but maybe I'm wrong. Are there download stats of x86-64 vs. arm64 for the Frescobaldi Flatpak?

https://flathub.org/stats/2023/

Choose a day and a json file, click on refs, then search for Frescobaldi and check which architectures have been downloaded. Or use wget and grep for a complete search.

I think we can ignore arm64 and see if any users will complain.

[hfiguiere]

I think we can ignore arm64 and see if any users will complain.

No.

[fedelibre]

We are talking about the development version of LilyPond. Most users don't need this. The stable version will be kept of course and it will be available for both x86-64 and arm64 architectures.

It would be interesting to know the number of arm64 users.

[fedelibre]

For the records, the update of LilyPond development versions is now automated. (well, the first test - pull #50 - required an extra commit by myself but normally this should not happen)