Hello, everyone! Talking about flatpak: there's even a bit aggressive criticism about it -- http://flatkill.org/ I am personally not against this technology completely, but probably more into making more of an effort to provide better system side libraries.
пн, 11 февр. 2019 г. в 00:16, Martin Kolman <martin.kol...@gmail.com>: > Sun, 10 Feb 2019 23:05:28 +0200 E.s. Rosenberg > <es.rosenberg+sailfishos....@gmail.com> > <es.rosenberg+sailfishos....@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.kol...@gmail.com > >: > >> Sun, 10 Feb 2019 09:56:06 +0200 Rinigus <rinigus....@gmail.com> >> <rinigus....@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 <dpur...@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....@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-unsubscr...@lists.sailfishos.org >>> >>> _______________________________________________ >>> SailfishOS.org Devel mailing list >>> To unsubscribe, please send a mail to >>> devel-unsubscr...@lists.sailfishos.org >> >> >> _______________________________________________ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org >> >> >> >> _______________________________________________ >> SailfishOS.org Devel mailing list >> To unsubscribe, please send a mail to >> devel-unsubscr...@lists.sailfishos.org > > > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org > > > > _______________________________________________ > SailfishOS.org Devel mailing list > To unsubscribe, please send a mail to > devel-unsubscr...@lists.sailfishos.org
_______________________________________________ SailfishOS.org Devel mailing list To unsubscribe, please send a mail to devel-unsubscr...@lists.sailfishos.org
