[digiKam-users] Future of digiKam bundles...

[Gilles Caulier-4]

Hi all users,

I would to give some feedback about the digiKam bundles migration advance...

The current files provided by the project are listed below :

- Linux AppImage 64 bits
- Linux AppImage 32 bits
- Macos Package installer 64 bits (based on Macports)
- Windows installer 64 bits (compiled with MXE - MinGW)
- Windows installer 32 bits (compiled with MXE - MinGW)

Current problems for these bundles are listed below :

- AppImage : not signed, do not support KIO extensions, do not support
ICU (language extension), not published on official repository.
- MacOS package : It's not relocatable, even if MacOS support well
this feature. I don't found the time to finalize yet the install
relocation support in bash script. Package is not published on MacOS
store.
- MXE Windows installer : not signed, not published on Windows store.
Do not support KIO extension.

But we have a new one starting to work and i working on : FlatPak

This one is signed, published of official repository automatically
(you can install it on Discover application for ex). It support ICU
and KIO too... FlatPak is compiled on KDE infrastructure nightly and
automatically. Only a 64 bits version is supported.

This want mean that AppImage end of life is near. We will still
publish officially the AppImage until 7.0.0, but later, if FlatPak do
the job as well, AppImage will be dropped...

For Windows, all the digiKam code compile fine under Microsoft Visual
C++ compiler. This is the goal to obtain a signed and published
version on Microsoft store. You can imagine that Microsoft will only
support the official Windows compiler, and not GCC to permit to sign
and publish application on the store. Don't forget, Microsoft is well
Closed Source (:=))))

Microsoft compiler is just the hell. It slow and require a Windows
operating system. The current cross compilation solution that we use
work fully under Linux, and compilation time are reduced by 4/5 ! A
full Linux Workflow is a non virus guaranty !

The Visual C++ workflow is also only available on 64 bits and is
computed on KDE infrastructure, but the installer compilation is
broken due to a weird configuration on KDE infrastructure. I currently
try to found a work around.

Personalty, i don't want to left MXE solution for the moment.

For MacOS, the KDE infrastructure based on Craft compilation framework
will be a solution to sing and publish a relocatable package for
Apple. digiKam do not compile yet due to  missing dependencies.

Voilà, i hope to be enough clear with these technical points.

My best

Gilles Caulier

[Jack Marxer]

Gilles Caulier,

Thank you so much for all the hard work you are doing on digiKam. I have been using the program for a long

time and look forward to the change for GNU/Linux from Appimage to FlatPack and I also hope that face

recognition will improve. I believe that 64-bit software is what is necessary for software this complicated and

comprehensive.

Yours gratefully,

Jack Marxer

On Sun, May 24, 2020 at 12:24 PM Gilles Caulier <[hidden email]> wrote:

Hi all users,

I would to give some feedback about the digiKam bundles migration advance...

The current files provided by the project are listed below :

- Linux AppImage 64 bits
- Linux AppImage 32 bits
- Macos Package installer 64 bits (based on Macports)
- Windows installer 64 bits (compiled with MXE - MinGW)
- Windows installer 32 bits (compiled with MXE - MinGW)

Current problems for these bundles are listed below :

- AppImage : not signed, do not support KIO extensions, do not support
ICU (language extension), not published on official repository.
- MacOS package : It's not relocatable, even if MacOS support well
this feature. I don't found the time to finalize yet the install
relocation support in bash script. Package is not published on MacOS
store.
- MXE Windows installer : not signed, not published on Windows store.
Do not support KIO extension.

But we have a new one starting to work and i working on : FlatPak

This one is signed, published of official repository automatically
(you can install it on Discover application for ex). It support ICU
and KIO too... FlatPak is compiled on KDE infrastructure nightly and
automatically. Only a 64 bits version is supported.

This want mean that AppImage end of life is near. We will still
publish officially the AppImage until 7.0.0, but later, if FlatPak do
the job as well, AppImage will be dropped...

For Windows, all the digiKam code compile fine under Microsoft Visual
C++ compiler. This is the goal to obtain a signed and published
version on Microsoft store. You can imagine that Microsoft will only
support the official Windows compiler, and not GCC to permit to sign
and publish application on the store. Don't forget, Microsoft is well
Closed Source (:=))))

Microsoft compiler is just the hell. It slow and require a Windows
operating system. The current cross compilation solution that we use
work fully under Linux, and compilation time are reduced by 4/5 ! A
full Linux Workflow is a non virus guaranty !

The Visual C++ workflow is also only available on 64 bits and is
computed on KDE infrastructure, but the installer compilation is
broken due to a weird configuration on KDE infrastructure. I currently
try to found a work around.

Personalty, i don't want to left MXE solution for the moment.

For MacOS, the KDE infrastructure based on Craft compilation framework
will be a solution to sing and publish a relocatable package for
Apple. digiKam do not compile yet due to  missing dependencies.

Voilà, i hope to be enough clear with these technical points.

My best

Gilles Caulier

Le 24/05/2020 à 12:24, Gilles Caulier a écrit :

> But we have a new one starting to work and i working on : FlatPak
>

the flatpak site ask for multi page reading... simple question: will the
package be run on linux like appimage, that is simply making it executable?

thanks
jdd

--
http://dodin.org

Dear Gilles (and the whole team),

 

thank you very much for all the effort you put into digikam (all of you)!

 

I was testing the flatpak 7.00 beta version just a few days ago, but ran into a problem that it complained about that it could not find my image collection on a certain disk (although I hadn't moved anything). When ignoring the error message, it started fine and showed most of my images, and the image collection was in my local collections. But next startup, it complained again. Changing file system permissions via flatseal did not really help. Any thoughts on this?

 

Cheers, Martin

 

Am Sonntag, 24. Mai 2020, 12:24:00 CEST schrieb Gilles Caulier:

> Hi all users,

>

> I would to give some feedback about the digiKam bundles migration advance...

>

> The current files provided by the project are listed below :

>

> - Linux AppImage 64 bits

> - Linux AppImage 32 bits

> - Macos Package installer 64 bits (based on Macports)

> - Windows installer 64 bits (compiled with MXE - MinGW)

> - Windows installer 32 bits (compiled with MXE - MinGW)

>

> Current problems for these bundles are listed below :

>

> - AppImage : not signed, do not support KIO extensions, do not support

> ICU (language extension), not published on official repository.

> - MacOS package : It's not relocatable, even if MacOS support well

> this feature. I don't found the time to finalize yet the install

> relocation support in bash script. Package is not published on MacOS

> store.

> - MXE Windows installer : not signed, not published on Windows store.

> Do not support KIO extension.

>

> But we have a new one starting to work and i working on : FlatPak

>

> This one is signed, published of official repository automatically

> (you can install it on Discover application for ex). It support ICU

> and KIO too... FlatPak is compiled on KDE infrastructure nightly and

> automatically. Only a 64 bits version is supported.

>

> This want mean that AppImage end of life is near. We will still

> publish officially the AppImage until 7.0.0, but later, if FlatPak do

> the job as well, AppImage will be dropped...

>

> For Windows, all the digiKam code compile fine under Microsoft Visual

> C++ compiler. This is the goal to obtain a signed and published

> version on Microsoft store. You can imagine that Microsoft will only

> support the official Windows compiler, and not GCC to permit to sign

> and publish application on the store. Don't forget, Microsoft is well

> Closed Source (:=))))

>

> Microsoft compiler is just the hell. It slow and require a Windows

> operating system. The current cross compilation solution that we use

> work fully under Linux, and compilation time are reduced by 4/5 ! A

> full Linux Workflow is a non virus guaranty !

>

> The Visual C++ workflow is also only available on 64 bits and is

> computed on KDE infrastructure, but the installer compilation is

> broken due to a weird configuration on KDE infrastructure. I currently

> try to found a work around.

>

> Personalty, i don't want to left MXE solution for the moment.

>

> For MacOS, the KDE infrastructure based on Craft compilation framework

> will be a solution to sing and publish a relocatable package for

> Apple. digiKam do not compile yet due to  missing dependencies.

>

> Voilà, i hope to be enough clear with these technical points.

>

> My best

>

> Gilles Caulier

>

 

 

[Gilles Caulier-4]

FlatPak is a bundle file as AppImage, but with a better integration in
Linux system. There is a door open through a socket to communicate
with DBus interface from host.

The FlatPak file, as i know, must be installed on your system using a
delegate application. KDE propose Discover program for that, but i'm
sure that other application exists.

From the delegate application you install the bundle as a native
package (RPM or DEB). In opposite to package, the bundles include all
dependencies required to run the target application.

So, certainly the Flatpak files must be stored somewhere, but where
exactly, i don't know. As i seen a FlatPak bundle must be store in a
repository, aka a store...

Voilà...

Gilles Caulier


Le dim. 24 mai 2020 à 16:15, [hidden email] <[hidden email]> a écrit :

>
> Le 24/05/2020 à 12:24, Gilles Caulier a écrit :
>
> > But we have a new one starting to work and i working on : FlatPak
> >
>
> the flatpak site ask for multi page reading... simple question: will the
> package be run on linux like appimage, that is simply making it executable?
>
> thanks
> jdd
>
> --
> http://dodin.org

[Chris Green]

Gilles Caulier <[hidden email]> wrote:
> FlatPak is a bundle file as AppImage, but with a better integration in
> Linux system. There is a door open through a socket to communicate
> with DBus interface from host.
>
> The FlatPak file, as i know, must be installed on your system using a
> delegate application. KDE propose Discover program for that, but i'm
> sure that other application exists.
>
That's rather important, I'm sure not everyone who runs Digikam runs
KDE.

> From the delegate application you install the bundle as a native
> package (RPM or DEB). In opposite to package, the bundles include all
> dependencies required to run the target application.
>
So why can't the FlatPack simply come as an RPM or DEB itself?  Even
better why can't it be in the normal repository for the distribution?

--
Chris Green
·

[Gilles Caulier-4]

Discover is just a solution to install a FlatPak bundle. All main
Linux desktop will certainly provide an delegate application.

More info for the sandoxed format is available here :

https://flatpak.org/

Gilles Caulier

Le dim. 24 mai 2020 à 17:18, Chris Green <[hidden email]> a écrit :

>
> Gilles Caulier <[hidden email]> wrote:
> > FlatPak is a bundle file as AppImage, but with a better integration in
> > Linux system. There is a door open through a socket to communicate
> > with DBus interface from host.
> >
> > The FlatPak file, as i know, must be installed on your system using a
> > delegate application. KDE propose Discover program for that, but i'm
> > sure that other application exists.
> >
> That's rather important, I'm sure not everyone who runs Digikam runs
> KDE.
>
> > From the delegate application you install the bundle as a native
> > package (RPM or DEB). In opposite to package, the bundles include all
> > dependencies required to run the target application.
> >
> So why can't the FlatPack simply come as an RPM or DEB itself?  Even
> better why can't it be in the normal repository for the distribution?
>
> --
> Chris Green
> ·
>

[etrigan63]

Flatpaks are generally hosted on www.flathub.org, but it is not a requirement. You can self-host the .flatpakref file yourself. The flatpak installation environment is managed by the distro and is not the developer's problem. Once you have your app converted to flatpak, the dependencies and libraries are all handled by the flatpak system.

On Sun, May 24, 2020 at 11:18 AM Chris Green <[hidden email]> wrote:

Gilles Caulier <[hidden email]> wrote:
> FlatPak is a bundle file as AppImage, but with a better integration in
> Linux system. There is a door open through a socket to communicate
> with DBus interface from host.
>
> The FlatPak file, as i know, must be installed on your system using a
> delegate application. KDE propose Discover program for that, but i'm
> sure that other application exists.
>
That's rather important, I'm sure not everyone who runs Digikam runs
KDE.

> From the delegate application you install the bundle as a native
> package (RPM or DEB). In opposite to package, the bundles include all
> dependencies required to run the target application.
>
So why can't the FlatPack simply come as an RPM or DEB itself?  Even
better why can't it be in the normal repository for the distribution?

--
Chris Green
·

Le 24/05/2020 à 17:41, Gilles Caulier a écrit :
> Discover is just a solution to install a FlatPak bundle. All main
> Linux desktop will certainly provide an delegate application.
>
> More info for the sandoxed format is available here :
>
> https://flatpak.org/
>

may be better here:

https://flatpak.org/setup/

(by distro)

but yet an other repository system :-(

jdd

--
http://dodin.org

[AndriusWild]

I think most flatpaks are hosted on flathub which is very similar to a distribution repository. You just need to activate it. I think flathub can be used from any Linux distribution which allows developers to maintain one version instead of supporting multiple builds e.g. Ubuntu, Manjaro, etc. 

I have been using GIMP flatpak over its version from Ubuntu repository for a while now and did not come across any malfunctions. I don't use GIMP extensively though. I think its startup is slower (at least first time after reboot) but overall functionality is good. 

I like all portable forms such as appimage, flatpak and snap and don’t know if either of them has advantage over the rest of them. Looks like Gilles does see an advantage of flatpak over appimage so if digiKam decided to go flatpak way I will be fine with that. Hopefully maintaining the flatpak won’t take more of your time than building appimages. 

On Sun, May 24, 2020 at 9:42 AM Gilles Caulier <[hidden email]> wrote:

Discover is just a solution to install a FlatPak bundle. All main
Linux desktop will certainly provide an delegate application.

More info for the sandoxed format is available here :

https://flatpak.org/

Gilles Caulier

Le dim. 24 mai 2020 à 17:18, Chris Green <[hidden email]> a écrit :
>
> Gilles Caulier <[hidden email]> wrote:
> > FlatPak is a bundle file as AppImage, but with a better integration in
> > Linux system. There is a door open through a socket to communicate
> > with DBus interface from host.
> >
> > The FlatPak file, as i know, must be installed on your system using a
> > delegate application. KDE propose Discover program for that, but i'm
> > sure that other application exists.
> >
> That's rather important, I'm sure not everyone who runs Digikam runs
> KDE.
>
> > From the delegate application you install the bundle as a native
> > package (RPM or DEB). In opposite to package, the bundles include all
> > dependencies required to run the target application.
> >
> So why can't the FlatPack simply come as an RPM or DEB itself?  Even
> better why can't it be in the normal repository for the distribution?
>
> --
> Chris Green
> ·
>

--

[Gilles Caulier-4]

yes, another one.

In fact, the FlatPak choice was done by KDE team, in favor than
AppImage. As KDE provide the infrastructure to build the bundle, it's
more simple to deploy.

You must know that all bundles, AppImage, MacOS, and Windows are build
on my computers, and it's take a while. If we can delegate this build
to an automatized workflow, it's better and safe for the future...

Gilles Caulier

Le dim. 24 mai 2020 à 17:50, [hidden email] <[hidden email]> a écrit :

>
> Le 24/05/2020 à 17:41, Gilles Caulier a écrit :
> > Discover is just a solution to install a FlatPak bundle. All main
> > Linux desktop will certainly provide an delegate application.
> >
> > More info for the sandoxed format is available here :
> >
> > https://flatpak.org/
> >
>
> may be better here:
>
> https://flatpak.org/setup/
>
> (by distro)
>
> but yet an other repository system :-(
>
> jdd
>
> --
> http://dodin.org

[AndriusWild]

I hope you won't focus on Microsoft Store version because ability to install
Store apps can be locked via group policy. But that is just selfish me
because I use digikam on work computer. I am sue many users will love having
digikam in the store.
Another problem, I a not sure what is the future of that store. I bought
into Microsoft Store on Windows 8 but where is it now? It perished along
with many other Microsoft initiatives.
I am all for portable installers like .exe, .appimage, etc.



--
Sent from: http://digikam.1695700.n4.nabble.com/digikam-users-f1735189.html

[AndriusWild]

Will you be able to modify the flatpak build script if needs be though?

I noticed with appimage you can quickly rebuild to see if a commit fixed a bug but I am not sure if that will work with flatpak.

On Sun, May 24, 2020 at 9:58 AM Gilles Caulier <[hidden email]> wrote:

yes, another one.

In fact, the FlatPak choice was done by KDE team, in favor than
AppImage. As KDE provide the infrastructure to build the bundle, it's
more simple to deploy.

You must know that all bundles, AppImage, MacOS, and Windows are build
on my computers, and it's take a while. If we can delegate this build
to an automatized workflow, it's better and safe for the future...

Gilles Caulier

Le dim. 24 mai 2020 à 17:50, [hidden email] <[hidden email]> a écrit :
>
> Le 24/05/2020 à 17:41, Gilles Caulier a écrit :
> > Discover is just a solution to install a FlatPak bundle. All main
> > Linux desktop will certainly provide an delegate application.
> >
> > More info for the sandoxed format is available here :
> >
> > https://flatpak.org/
> >
>
> may be better here:
>
> https://flatpak.org/setup/
>
> (by distro)
>
> but yet an other repository system :-(
>
> jdd
>
> --
> http://dodin.org

of course I'm fine with any solution you find better 😁

--
http://dodin.org

[Gilles Caulier-4]

yes, i can, but the changes are limited.. File is here :

https://invent.kde.org/packaging/flatpak-kde-applications/-/blob/master/org.kde.digikam.json

Gilles Caulier

Le dim. 24 mai 2020 à 18:05, Andrey Goreev <[hidden email]> a écrit :

>
> Will you be able to modify the flatpak build script if needs be though?
> I noticed with appimage you can quickly rebuild to see if a commit fixed a bug but I am not sure if that will work with flatpak.
>
> Thanks,
> Andrey
>
>
> On Sun, May 24, 2020 at 9:58 AM Gilles Caulier <[hidden email]> wrote:
>>
>> yes, another one.
>>
>> In fact, the FlatPak choice was done by KDE team, in favor than
>> AppImage. As KDE provide the infrastructure to build the bundle, it's
>> more simple to deploy.
>>
>> You must know that all bundles, AppImage, MacOS, and Windows are build
>> on my computers, and it's take a while. If we can delegate this build
>> to an automatized workflow, it's better and safe for the future...
>>
>> Gilles Caulier
>>
>> Le dim. 24 mai 2020 à 17:50, [hidden email] <[hidden email]> a écrit :
>> >
>> > Le 24/05/2020 à 17:41, Gilles Caulier a écrit :
>> > > Discover is just a solution to install a FlatPak bundle. All main
>> > > Linux desktop will certainly provide an delegate application.
>> > >
>> > > More info for the sandoxed format is available here :
>> > >
>> > > https://flatpak.org/
>> > >
>> >
>> > may be better here:
>> >
>> > https://flatpak.org/setup/
>> >
>> > (by distro)
>> >
>> > but yet an other repository system :-(
>> >
>> > jdd
>> >
>> > --
>> > http://dodin.org

[AndriusWild]

Is it possible to have few flatpaks of digiKam at the same time? I find appimages handy to test new builds because they are just files in a folder and I can pick which one to launch at any given time. 

On Sun, May 24, 2020 at 11:41 AM Gilles Caulier <[hidden email]> wrote:

yes, i can, but the changes are limited.. File is here :

https://invent.kde.org/packaging/flatpak-kde-applications/-/blob/master/org.kde.digikam.json

Gilles Caulier

Le dim. 24 mai 2020 à 18:05, Andrey Goreev <[hidden email]> a écrit :
>
> Will you be able to modify the flatpak build script if needs be though?
> I noticed with appimage you can quickly rebuild to see if a commit fixed a bug but I am not sure if that will work with flatpak.
>
> Thanks,
> Andrey
>
>
> On Sun, May 24, 2020 at 9:58 AM Gilles Caulier <[hidden email]> wrote:
>>
>> yes, another one.
>>
>> In fact, the FlatPak choice was done by KDE team, in favor than
>> AppImage. As KDE provide the infrastructure to build the bundle, it's
>> more simple to deploy.
>>
>> You must know that all bundles, AppImage, MacOS, and Windows are build
>> on my computers, and it's take a while. If we can delegate this build
>> to an automatized workflow, it's better and safe for the future...
>>
>> Gilles Caulier
>>
>> Le dim. 24 mai 2020 à 17:50, [hidden email] <[hidden email]> a écrit :
>> >
>> > Le 24/05/2020 à 17:41, Gilles Caulier a écrit :
>> > > Discover is just a solution to install a FlatPak bundle. All main
>> > > Linux desktop will certainly provide an delegate application.
>> > >
>> > > More info for the sandoxed format is available here :
>> > >
>> > > https://flatpak.org/
>> > >
>> >
>> > may be better here:
>> >
>> > https://flatpak.org/setup/
>> >
>> > (by distro)
>> >
>> > but yet an other repository system :-(
>> >
>> > jdd
>> >
>> > --
>> > http://dodin.org

--

[Mica Semrick]

Yes, it is possible to have multiple version of the same application installed at the same time.

In addition, the updates come from a repo and can be updated along with everything else.on your system via Discover or gnome software. Or, from the CLI using "flatpak update".

I've worked on quite a few flatpak applications, RawTherapee, darktable, and geeqie, and I find that once the initial packaging is done, it is quite easy to maintain over time.

On May 24, 2020 10:44:35 AM PDT, Andrey Goreev <[hidden email]> wrote:

Is it possible to have few flatpaks of digiKam at the same time? I find appimages handy to test new builds because they are just files in a folder and I can pick which one to launch at any given time. 

On Sun, May 24, 2020 at 11:41 AM Gilles Caulier <[hidden email]> wrote:

yes, i can, but the changes are limited.. File is here :

https://invent.kde.org/packaging/flatpak-kde-applications/-/blob/master/org.kde.digikam.json

Gilles Caulier

Le dim. 24 mai 2020 à 18:05, Andrey Goreev <[hidden email]> a écrit :
>
> Will you be able to modify the flatpak build script if needs be though?
> I noticed with appimage you can quickly rebuild to see if a commit fixed a bug but I am not sure if that will work with flatpak.
>
> Thanks,
> Andrey
>
>
> On Sun, May 24, 2020 at 9:58 AM Gilles Caulier <[hidden email]> wrote:
>>
>> yes, another one.
>>
>> In fact, the FlatPak choice was done by KDE team, in favor than
>> AppImage. As KDE provide the infrastructure to build the bundle, it's
>> more simple to deploy.
>>
>> You must know that all bundles, AppImage, MacOS, and Windows are build
>> on my computers, and it's take a while. If we can delegate this build
>> to an automatized workflow, it's better and safe for the future...
>>
>> Gilles Caulier
>>
>> Le dim. 24 mai 2020 à 17:50, [hidden email] <[hidden email]> a écrit :
>> >
>> > Le 24/05/2020 à 17:41, Gilles Caulier a écrit :
>> > > Discover is just a solution to install a FlatPak bundle. All main
>> > > Linux desktop will certainly provide an delegate application.
>> > >
>> > > More info for the sandoxed format is available here :
>> > >
>> > > https://flatpak.org/
>> > >
>> >
>> > may be better here:
>> >
>> > https://flatpak.org/setup/
>> >
>> > (by distro)
>> >
>> > but yet an other repository system :-(
>> >
>> > jdd
>> >
>> > --
>> > http://dodin.org

--

[digikam-2]

On Sun, 24 May 2020 09:55:33 -0600
Andrey Goreev <[hidden email]> wrote:

> I think its startup is slower (at least first time after reboot)
> but overall functionality is good. I like all portable forms such
> as appimage, flatpak and snap and don’t know if either of them has
> advantage over the rest of them. Looks like Gilles does see an
> advantage of flatpak over appimage so if digiKam decided to go
> flatpak way I will be fine with that.

* What is the speed of the flatpaked app?
* Is it slower than the one from the distribution?
* Is it faster or slower than the appimage?

Thanks

--
sknahT

vyS

[Chris Green]

Gilles Caulier <[hidden email]> wrote:
> Discover is just a solution to install a FlatPak bundle. All main
> Linux desktop will certainly provide an delegate application.
>
It seems all wrong to me somehow.

Either (like Appimage) you download a file (downloading any old way
you want, you usual way of doing it, ftp, wget, whatever) and it's a
standalone program with no dependencies *OR* you have something that
uses the distribution's standard format for handling dependencies etc.

It sounds like a FlatPak is some sort of horrible halfway house.

--
Chris Green
·

[AndriusWild]

I think flatpaks are standalone and have no dependencies. Looks like they allow for better integration with some desktops which is valuable to many users (KDE Plasma users for instance). And also looks like it gets building applications off Gilles’ plate allowing him to spend more time coding, enjoy family time or finally get that ol’ BWM motorcycle that has been sitting in the garage for years up and running again so I say why not?

On Sun, May 24, 2020 at 2:03 PM Chris Green <[hidden email]> wrote:

Gilles Caulier <[hidden email]> wrote:
> Discover is just a solution to install a FlatPak bundle. All main
> Linux desktop will certainly provide an delegate application.
>
It seems all wrong to me somehow.

Either (like Appimage) you download a file (downloading any old way
you want, you usual way of doing it, ftp, wget, whatever) and it's a
standalone program with no dependencies *OR* you have something that
uses the distribution's standard format for handling dependencies etc.

It sounds like a FlatPak is some sort of horrible halfway house.

--
Chris Green
·

--