[SailfishDevel] qt upgrade

Martin Kolman martin.kolman at gmail.com
Sun Feb 10 21:16:36 UTC 2019


Sun, 10 Feb 2019 23:05:28 +0200 E.s. Rosenberg 
<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 support.

Looks like the Purism Librem 5 open hardware phone project aims to use 
Flatpaks for third party application distribution:

https://www.phoronix.com/scan.php?page=news_item&px=Purism-PureOS-Store-Flatpaks

>
> Just my 2c
>
> Op zo 10 feb. 2019 om 22:56 schreef Martin Kolman 
> <martin.kolman at gmail.com <mailto:martin.kolman at gmail.com>>:
>
>     Sun, 10 Feb 2019 09:56:06 +0200 Rinigus <rinigus.git at gmail.com>
>     <mailto:rinigus.git at gmail.com>:
>>     Morning,
>>
>>     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 Kirigami
>>
>>     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 Qt.
>>
>>     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.
>
>>
>>
>>     Cheers,
>>
>>     Rinigus
>>
>>     On Sun, Feb 10, 2019 at 8:55 AM Dmitriy Purgin <dpurgin at gmail.com
>>     <mailto: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.
>>
>>         Cheers
>>         Dmitriy
>>
>>         On Sat, Feb 9, 2019 at 6:44 PM rinigus <rinigus.git at gmail.com
>>         <mailto:rinigus.git at gmail.com>> wrote:
>>
>>             Hi,
>>
>>             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 considered?
>>
>>             Cheers,
>>
>>             Rinigus
>>
>>             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
>>             <mailto:devel-unsubscribe at lists.sailfishos.org>
>>
>>         _______________________________________________
>>         SailfishOS.org Devel mailing list
>>         To unsubscribe, please send a mail to
>>         devel-unsubscribe at lists.sailfishos.org
>>         <mailto:devel-unsubscribe at lists.sailfishos.org>
>>
>>
>>     _______________________________________________
>>     SailfishOS.org Devel mailing list
>>     To unsubscribe, please send a mail todevel-unsubscribe at lists.sailfishos.org  <mailto:devel-unsubscribe at lists.sailfishos.org>
>
>     _______________________________________________
>     SailfishOS.org Devel mailing list
>     To unsubscribe, please send a mail to
>     devel-unsubscribe at lists.sailfishos.org
>     <mailto: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...
URL: <https://lists.sailfishos.org/pipermail/devel/attachments/20190210/d49e3642/attachment-0001.html>


More information about the Devel mailing list