enzo1982 / freac

The fre:ac audio converter project
https://www.freac.org/
GNU General Public License v2.0
1.39k stars 72 forks source link

Flatpak 1.1.7 still uses FLAC 1.3.4 #458

Open cleveHEX opened 1 year ago

cleveHEX commented 1 year ago

Installed fre:ac from Flathub, is there any solution?

enzo1982 commented 1 year ago

The Flatpak version of fre:ac uses codecs provided by the Freedesktop Platform runtime if available. The next major release of the Freedesktop Platform will include FLAC 1.4.x.

The maintainers of the Flatpak/Flathub infrastructure discourage shipping custom versions of libraries already included in the runtime. However, I guess it may be alright to ship an updated FLAC as the new version adds major new features like 32 bit support that are otherwise missing. I'll consider that for the next update (which will happen soon as there are a number of issues that need to be addressed).

Until then, please use the AppImage or Snap version or a custom build to use FLAC 1.4.2 with fre:ac.

cleveHEX commented 1 year ago

I still face this issue, does fre:ac still use the older runtime?

Lee-Carre commented 12 months ago

@cewbdex

Based on what enzo1982 said, you need to nag Flathub maintainers to update their bundled libraries. That solves the problem for all Flatpak software & users.

cleveHEX commented 12 months ago

Flathub has 23.08 of freedesktop SDK available, I have found fre:ac still uses 22.08: https://github.com/flathub/org.freac.freac/blob/master/org.freac.freac.json

Lee-Carre commented 12 months ago

Flathub has [v]23.08 of freedesktop SDK available, I have found fre:ac still uses [v]22.08

Fair point, then. I'm not familiar with Flatpak/Flathub, and thus plead ignorance.

I checked the (recent) commit history, and there are no relevant commits since v1·1·7 (based on their comment) for this problem. Probably because it may not be a trivial change to migrate to a newer SDK.

I still face this issue

For context, I've read elsewhere that enzo1982 is busy with other areas of life (and developing Fre:AC is, I gather, a hobby, anyway). I'm sure he'll address this, in future, though.

You might consider using a non-Flatpak build of Fre:AC, until the situation changes.

Else, see if there's some hack to use FLAC v1·4 with Flathub SDK v22·08. 🤷‍♂️ A simple approach might be to change 22·08 to 23·08 in the relevant files, recompile/repackage, and see if Fre:AC functions without any (other) code changes; if the SDKs remain compatible in terms of the functions/libraries which Fre:AC uses, then this may work. Again, I'm oblivious to Flakpak/Flathub.

Ultimately, it depends how important FLAC v1·4 is to you, and how much of a kludge you're willing to accept/endure/make, in order to have it.

From my own experience, I'd stick with the stock package for now, since Fre:AC does still function (and auto-updates will install a newer version when available). Yes, the FLACs it produces may not be optimal, but you could always re-encode them later, else produce them on another host (or, have Fre:AC produce uncompressed files which you then encode into FLACs using a separate (v1·4) encoder; since there's freaccmd you could always script this set of commands).

Else, failing all that, persuade someone to produce the necessary pull request, which makes the necessary changes you wish. That's then much less work for enzo1982.

cleveHEX commented 12 months ago

While I appreciate you try to offer me other solutions, there is nothing I did not know already. I have just made an update to the ticket, because the SDK fre:ac uses got new version, to notify enzo in case he did not know. I am not forcing him to do anything (seems like he has a break I didn't know about at the time writing, which is totally understandable and I hope he is doing well), not sure why you think I do. Maybe if you don't understand flatpak system, you should not comment on issues regarding it with false statements. Afaik Enzo is the only person that can do anything about this, as he is probably the only one with write access to FH repo.