[SailfishDevel] qt upgrade
rinigus.git at gmail.com
Sun Feb 10 21:33:05 UTC 2019
I have the mapping applications distributed via Flathub and the experience
has been very good so far. In some aspects its similar to what we have now
- you rely on the runtime (Platform in flatpak lingo) and have to bundle
all extra libs with it. Libs are described using via build scripts and
archive/git (hash, commit id). In my case, its quite a few. As for overall
experience - you get support with packaging through review of the
corresponding pull request and the packages are build on their servers
(kind of OBS as a frontend for the store). Worked quite well and got help
there as well.
Would be good to have flatpak support, but I am not sure what are the
kernel requirements for it.
Back to the original question, Alexander: thanks for sorting it out, I'll
try tomorrow. I do wonder why the keyboard doesn't get activated, though.
Any tips regarding it?
Thanks for the feedback and discussion,
On Sun, Feb 10, 2019 at 11:16 PM Martin Kolman <martin.kolman at gmail.com>
> Sun, 10 Feb 2019 23:05:28 +0200 E.s. Rosenberg
> <es.rosenberg+sailfishos.org at gmail.com>
> <es.rosenberg+sailfishos.org at gmail.com>:
> Flatpak would make our phones so much more insecure - instead of Jolla
> updating bad/insecure libraries (which also happens at a pace that leaves
> to be desired) you become dependent on the devs of the application you are
> using doing that.
> I don't think this is correct. Unlike for example App image where
> developers AFAIK *do* have to bundle everything, Flatpak has a concept of
> shared application runtimes. As long an application uses sensitive
> libraries (mainly crypto related) from the runtime, it's not really
> different from the current system with shared system libraries - as long as
> the runtime is being properly maintained.
> Also both main app distribution channels in Sailfish OS are taking binary
> RPMs only and there is nothing really preventing developers from bundling
> about anything already.
> Since Jolla tries to have one of its' claims to fame be security it seems
> that flatpak support should be just about the last thing they should
> Looks like the Purism Librem 5 open hardware phone project aims to use
> Flatpaks for third party application distribution:
> Just my 2c
> Op zo 10 feb. 2019 om 22:56 schreef Martin Kolman <martin.kolman at gmail.com
>> Sun, 10 Feb 2019 09:56:06 +0200 Rinigus <rinigus.git at gmail.com>
>> <rinigus.git at gmail.com>:
>> suggestion to consider Qt 5.12 in /opt comes from the following:
>> * newer web engine
>> * we can use and contribute to the code written for Plasma with its
>> It will not bring native new applications, we don't have Silica for it.
>> However, I personally think it makes more sense to use and help out with
>> the development of Linux-based solutions than to use Android-provided web
>> browsers through SFOS Android compatibility layer.
>> This would not to be intended to be installed in /usr and having platform
>> supporting multiple Qt versions at once. I have no idea whether its
>> possible and no desire to get into messing up the system layer.
>> Dmitriy: I don't know whether you can mix different Qt versions in the
>> same application. In this respect, yes, you could probably ship Qt 512
>> stack fully, but would probably have to stay away from the system-provided
>> Leszek: fragmentation is to be considered, indeed. But, as far as I
>> understood, it makes sense to develop browser against the last version of
>> Qt. In some aspect, using Qt59 on SFOS contributes to fragmentation in a
>> way that we, on SFOS, will be using the version that is slowly phased out
>> already. At present, Kirigami is developed using Qt512, with Qt511 version
>> having at least one bug that will never be fixed. Not sure whether Kirigami
>> runs against Qt59. So, if we would like to run Kirigami apps, Qt 5.12 is
>> most probably needed.
>> I hope eventually support for using Flatpak for package distribution is
>> added to Sailfish OS, as that would make it possible to decouple the
>> "system" Qt version from the "application" Qt version. Updating the system
>> version would not longer risk breakage in third party applications and
>> could be done on it's own, likely slower, pace. On the other hand updating
>> the "application" Qt would mean just releasing a new Flatpak runtime with
>> the updated Qt version. Old application would continue working with old
>> runtime/-s while new apps would be able to use all the new goodies
>> available via the new runtime. IIRC this is already being done for Qt on
>> the desktop via the Flatpak runtimes maintained by the KDE project.
>> Of course there are some trade-offs and things to consider - you would
>> have to, in some capacity, maintain multiple versions of Qt and system
>> libraries in parallel. On the other hand, each Qt version would be either a
>> "system" only one or "application" one. Not one that needs to be perfect or
>> else both the system and apps will stop working. This could help to reduce
>> the maintenance burden somewhat.
>> Also, even if it would be nice to keep all older runtimes around so that
>> all old (and likely abandoned) apps continue working, it would be likely
>> prudent to stop maintaining old runtimes after a while to keep the
>> maintenance burden reasonable.
>> There is also a question if this is something that community can at least
>> start or Jolla involvement is needed. As already mentioned in the thread,
>> due to Silica still being closed source a community only Flatpak effort
>> likely could not support running Silica applications. A Jolla provided
>> runtime - or open source Silica - would be needed for that.
>> On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin <dpurgin at gmail.com> wrote:
>>> Hi all,
>>> if there are some parts of the newer Qt you need in your app, you can
>>> always compile it yourself, link your app against the newer version and
>>> ship these libraries with your app.
>>> On Sat, Feb 9, 2019 at 6:44 PM rinigus <rinigus.git at gmail.com> wrote:
>>>> sounds like there are porting and licensing issues on the way of
>>>> getting qt 5.9 for SFOS (see logs from the last #mer-meeting). Its all
>>>> understandable, but it would be great to get a way forward. Not sure
>>>> whether it has been considered by others and I wonder whether we can make a
>>>> separate Qt 5.12 packages for /opt/qt512?
>>>> From a quick test, it is possible to run non-silica applications as
>>>> well (tested with qmlscene and QML with plain Window). In that test, even
>>>> keyboard worked as expected. Look was non-native, but let it be for now.
>>>> So, I wonder, whether its possible to get Qt 5.12 compiled with
>>>> /opt/qt512 prefix and then use it for development using the latest libs
>>>> (new web browser?) and collaborate with other mobile Linux'es out there. As
>>>> far as I remember, Wayland was rather old and, maybe, it will preclude Qt
>>>> 5.12 compilation. @mal, though, had a newer version around and it may serve
>>>> a purpose for such project. Is there anything else that should be
>>>> PS: Please consider it as request-for-comment and not as any kind of
>>>> statement nor call-for-action :)
>>>> SailfishOS.org Devel mailing list
>>>> To unsubscribe, please send a mail to
>>>> devel-unsubscribe at lists.sailfishos.org
>>> SailfishOS.org Devel mailing list
>>> To unsubscribe, please send a mail to
>>> devel-unsubscribe at lists.sailfishos.org
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org
>> SailfishOS.org Devel mailing list
>> To unsubscribe, please send a mail to
>> devel-unsubscribe at lists.sailfishos.org
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to devel-unsubscribe at lists.sailfishos.org
> SailfishOS.org Devel mailing list
> To unsubscribe, please send a mail to
> devel-unsubscribe at lists.sailfishos.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel