32 bits digiKam bundles : still necessary ?

[Gilles Caulier]

2017-11-03 8:06 GMT+01:00 Remco Viëtor <remco.vietor at wanadoo.fr>:

> On jeudi 2 novembre 2017 11:52:58 CET Gilles Caulier wrote:
> > Hi all,
> >
> > Just few words in this room about the bundles files created at each
> digiKam
> > releases.
> >
> > Currently we provide :
> >
> > - 2 Windows installers : 32 and 64 bits.
> > - 1 MacOS PKG : 64 bits.
> > - 2 Linux AppImage : 32 and 64 bits.
> >
> > I plan to drop the 32 bits versions and let's only the 64 bits.
> >
> > Why ? because 32 bits become more and more difficult to build, especially
> > the AppImage. I spare a lots of time to maintain the bundles compilation
> > workflow. All this time passed at this task is not used to really code in
> > digiKam.
> >
> > About AppImage, this needs to be compiled from scratch. I use CentOS 6 to
> > prevent broken binary compatibility with glibc with recent Linux distro.
> >
> > CentOS 6 32 bits is not maintained anymore. To get last compiler version
> > supporting C++11 at least to compile Qt5 and KF5, i need to branch the
> > distro to Scientific Linux from the CERN which provide extra repository.
> > But this become step by step complicated to maintain in time. I tried to
> > use last Qt 5.9.2 and the compiler version is not enough. And i don't
> talk
> > about last KF5 version witch use more and more C++14 rules in source code
> > which are not supported well by old compilers.
> >
> > Note : The Windows 32 bits croos-compiled with MXE is not problematic,
> but
> > to be homogeneous, i will drop this one too.
> >
> > Another point in favor of 64 bits against 32 bits version : 32 bits is
> > limited in absolute to 4 GB of RAM, lees of course delegate to OS. So
> > digiKam will quickly saturate the memory if you try to manage huge images
> > (as panorama for ex).
> >
> > An last point : 32 bits systems become less and less used. My viewpoint
> is
> > to promote 64 bits instead now.
> >
> > Users viewpoints are welcome.
> > Thanks in advance
>
> I've switched to 64-bit years ago, so /for me/, maintaining a 32-bit
> version
> looks like a waste of time. And from the other answers, there's /perhaps/
> one
> in there who is still using a 32-bit digikam version.
>
> Is it possible to freeze a 32-bit source (for older OS versions), and only
> provide builds for 64-bit versions? After all, the 32-bit OSs seem to be
> outdated (at least as far as Linux is concerned), so users are already
> behind
> on security patches. If you provide source tarballs, the 32-bit users will
> still have access to the program, but of course w/o the latest
> functionality.
>

I will be more precise here. There is no digiKam 32 bits branch dedicated
to 32 OS.
The digiKam code is the same everywhere.

The problematic is about the dependencies library where i need to apply
some patch while compilation of bundles 32 bits.

The most problematic is KF5. Until 5.36, it was easy, with more recent
versions become infernal.

Until now QT5 5.9.1 compile fine, New 5.9.2 start to break the
compatibility.


>
> And if the libraries Digikam depends on are moving more and more to
> C++11/C+
> +14, older systems will get forced out sooner rather than later anyway.
> It's
> unreasonable to expect a small player wasting time for a platform the big
> ones
> have dropped...
>
> Btw, I thought digikam was moving away from the KDE frameworks, and aimed
> to
> be 'QT only'?
>
>
digiKam is not fully a pure Qt5 application. It still 15/20 % of KF5
dependencies, the most complex to remove.

Look the full list of digiKam dependencies here :

https://cgit.kde.org/digikam-software-compilation.git/tree/DEPENDENCIES

Note : "opt" is this list want mean optional. Look well the explaination on
the right side of list.



> Remco
>
> P.S. If indeed the Windows 32-bit build cross-compiles w/o problems,
> deprecate
> it for a year or so after dropping the other 32-bit builds?
>

So typically for 6.0.0 main release...

Gilles Caulier
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20171103/e0ee500f/attachment.html>