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

[Mica Semrick]

If you want to continue to use your distro's native package, you should do that. Likewise if someone wants to volunteer to maintain the AppImage, they should do that.

That doesn't stop the project from using flatpak; they're not mutually exclusive.

On May 25, 2020 2:40:57 AM PDT, Stuart T Rogers <stuart at stella-maris.org.uk> wrote:
>Yes I agree for some limited situations it may have a use. I for one 
>have used appimage to try out a new version but my distro (a rolling 
>release) is never far behind with providing stable releases of Digikam.
>
>While the library thing may well need security fixes if I have the 
>library on my system normally it will get security fixes probably
>almost 
>as soon as they become available, how will I know these libraries will 
>need updating in the flatpak and whether or not the package has been 
>updated?
>
>Stuart
>
>On 25/05/2020 10:34, Remco Viëtor wrote:
>> On lundi 25 mai 2020 10:38:31 CEST Stuart T Rogers wrote:
>>> Having read a bit about flatpak now I do have some concerns.
>>>
>>> Firstly it seems that the actual deliverable will be considerably
>larger
>>> than the normal install of Digikam say on openSUSE because it will
>need
>>> to bundle in all the required other software it needs whether or not
>the
>>> base OS already has the correct levels and versions installed.
>> 
>> That would be the same for appimage or any other similar packaging.
>And it's
>> what is needed to make the package independent of the distribution
>and its
>> versioning.
>> 
>>> Secondly while it runs in a sandbox it will likely increase the
>memory
>>> requirement needed over what would normally be used because all the
>>> additional code needed for execution will be loaded even if it
>already
>>> exists and is loaded in the OS.
>>>
>>> Thirdly this seems to me to be a sledgehammer to crack a nut since I
>>> have not heard of any security breaches being caused by running
>Digikam,
>>> yes some other applications maybe should be sandboxed because of
>what
>>> they do but I do not see the need for this with Digikam.
>> 
>> But I have seen security updates for *libraries* dealing with the
>image
>> formats used by Digikam, like png.  So while the digikam code itself
>might not
>> need sandboxing, this doesn't hold for the needed libraries.
>> 
>>> Lastly it needs additional software installed on my system which
>>> currently I do not use. Appimage does not need anything in addition
>to
>>> be able to test a new version of Digikam.
>> 
>> That is the price for (semi-)automatic upgrades for the flatpaks.
>Appimage
>> does not provide a way to upgrade to newer versions.
>>   
>>> This seems to me to be a solution looking for a purpose.
>> 
>> Maybe. But I've had cases where the distribution-provided version was
>either
>> much older than the (then) current version or crippled as my
>distribution
>> didn't include a library or included a too old version.
>> 
>> So flatpak and appimage do have a use. That doesn't mean that having
>> distribution-maintained repositories is now superfluous, but for
>programs that
>> have a relatively small user-base, flatpak and similar have
>advantages.
>> 
>> Remco
>> 
>> 
>> 
>> 
>> 
>
>-- 
>Website: https://www.stella-maris.org.uk
>or:      https//www.broadstairs.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20200525/6f029db7/attachment.htm>