search

linuxmint / mintcommon

23 stars 25 forks source link

_flatpak.py: Don't fail an entire job if one package fails to install #36

Closed mtwebster closed 5 years ago

mtwebster commented 5 years ago

(as long as it's not the application's package iself).

gm10 commented 5 years ago

Having a hard time understanding this one, maybe because I don't do flatpaks: Does one package failing to install not mean that the user will not be able to run the application they were trying to install, i.e. something that you would want to communicate to the user?

mtwebster commented 5 years ago

I don't like this much myself. Based on what I knew about package managers, if a dependency package failed to install, there was no point finishing the installation here, so we would abort.

Apparently with flatpaks, failure is not guaranteed.

flatpak install flathub org.blender.Blender

Without this patch, the above command will fail to install all dependencies, but successfully install (and execute) blender. There are some other packages currently that are exhibiting this.

If you try to install org.freedesktop.Platform.openh264 on its own, it fails. But if you let flatpak attempt to install it as part of the installation of blender, it merely warns on that package failure, but the blender install itself succeeds.

We're basically making mintinstall behave this same way. There will be a notification if the application package itself fails, which is really all that matters.

The failure itself is supposedly because our version of flatpak on mint is too old, but from what I gather, that package fails to install with a valid version also.

here's a link to one bug report: https://github.com/linuxmint/mintinstall/issues/260

gm10 commented 5 years ago

So basically you're forcing partial installation of badly packaged flatpaks to give the user at least something to work with? I guess it's safe to assume that the applications will generally still work but video playback or encoding requiring the h264 codec will fail or even crash those applications. But the next case with problematic packaging may fail at installing an entire runtime and you would still be telling the user that everything is fine.

I understand the short-term motivation for this but I don't agree with the approach at all, I will not be picking this one into my fork. IMHO the proper solution would be either to get the maintainer of the openh264 flatpak to fix their packaging or you guys to backport the newer flatpak release, whichever may be applicable here.

Thank you very much for taking the time to explain though!

refi64 commented 5 years ago

There isn't really any workaround for the openh264 extension afaik. I think legally, they can't redistribute some of the files, so they need to use the new extra-data support for extensions.

Erick555 commented 5 years ago

@gm10 extensions in flatpak ecosystem are optional, lack of them shouldn't cause an app to fail. Lack of h264 codec shouldn't cause app to fail because there is dummy lib available in runtime for that case.

openh264 flatpak extension is part of freedesktop-sdk and maintained alongside it. The reason it fails to install is that it needs feature from latest flatpak version to work. This is being backported to older flatpak releases, currently it works in flatpak >=1.0.9, >=1.2.5 and >=1.4.2 and distros are strongly recommended to update to one of those. Nevertheless failure to install openh264 was expected and planned for older flatpak versions. It doesn't cause flatpak cli transaction to fail and every failure of gui helper in that case is a bug which should be fixed there.

gm10 commented 5 years ago

@Erick555

Lack of h264 codec shouldn't cause app to fail because there is dummy lib available in runtime for that case. [...] It doesn't cause flatpak cli transaction to fail and every failure of gui helper in that case is a bug which should be fixed there.

Thanks for the clarification, I don't even have the flatpak client installed so my knowledge about the inner workings of this is basically zero. Based on what you said, maybe this patch should be limited to extensions then? I am still thinking of the case where a vital runtime fails to install and not an optional extension. An error message should be provided in any case as far as I am concerned.

Erick555 commented 5 years ago

The crucial part and the reason openh264 installation fails on older flatpak is that it has explicit version requirement in its manifest. The reasoning here is that failing to install something that requires newer flatpak than installed on system isn't a real failure but expected and right outcome. So it would be optimal to make exception for such special case if possible (flatpak requirement not meet = warn but not fail whole transaction) and let all other cases fail as before.