Natron 2.6 (Qt5) binary distrib for Linux

[devernay]

Natron 2.6 will probably require some rework of the script that build the distribution/installer.

We may want to abandon the Qt installer, and maybe build snap/AppImage distribs instead

[rodlie]

We may want to abandon the Qt installer, and maybe build snap/AppImage distribs instead

Personally I'm not a big fan of snaps etc, but that's just my opinion (mounting disk images to use an app is IMHO a bit silly). Any reason why we should remove the installer?

As long as the binary tarball is still kept I'm happy :)

[YakoYakoYokuYoku]

Would be a good idea to use GitHub actions for the distribs, should we give it a shot?

[rodlie]

Maybe.

• the Linux build must be run in a docker for CentOS7, should be trivial to get working
• The Windows build will require several "hacks" to get working, but it should work (at least does that for openfx-arena)
• macOS is a bit tricky as we support several versions, and GitHub don't

I tried doing this with Travis, but the time limit was not high enough. GitHub support up to 6 hours I think, so we are good there. One build + tests will probably take 2 hours.

[alexmyczko]

I'm trying hard to get Natron built on Debian sid (where python2 and qt4 do not exist anymore), but I keep failing, no matter how hard I read:
https://github.com/NatronGitHub/Natron/blob/RB-2.5/INSTALL_LINUX.md

maybe I'm missing something? But if you're interested in having Natron be part of Debian (Ubuntu, Raspbian) officially, help is welcome.

That's part of the output:

sh: 1: python2: not found
sh: 1: python2: not found
sh: 1: python2: not found
sh: 1: python2-config: not found
sh: 1: python2-config: not found
sh: 1: python2-config: not found

here's where i work: sid.ethz.ch/debian/natron/2022/
althouth openfx-* is part of it, i'm able to build -text and -misc separately: see the respective directories on the same host.

things could be sped up if any of you is also on irc... (/msg tarzeau)

[devernay]

Personally I'm not a big fan of snaps etc, but that's just my opinion (mounting disk images to use an app is IMHO a bit silly). Any reason why we should remove the installer?

The current installer is Qt4 and it's ugly.

Personally, I'm not a big fan of installers:

• they require a GUI or some prior knowledge to change the installation location
• they often write in a filesystem shared between users, which is normally where the OS goes
• you know how to install, but the installation procedure is often impossible or hidden

As long as the binary tarball is still kept I'm happy :)

There's no reason to remove that.

[rodlie]

The current installer is Qt4 and it's ugly.

There is nothing stopping us from updating it.

they often write in a filesystem shared between users, which is normally where the OS goes

It writes to $HOME as default last time I checked.

you know how to install, but the installation procedure is often impossible or hidden

We have a uninstall icon, users can also just remove the folder.

Anyway, I'm not going to argue about this, remove it if you want. Note that an AppImage might not necessarily be a better solution.

[cgvirus]

Folks,
Snap is very limited when comes to server workstation. They are often locked and offline.
Appimage is nice, but probably fall into difficulties with plugins and external OFXs (Not sure). I use appimage for most apps these days in Linux.
For Natron tar ball and portable is nice IMHO.

[alexmyczko]

I was curious what speaks against native debian packages? It what works best really for multiple decades of years...

[rodlie]

I was curious what speaks against native debian packages?

We provide universal binaries for Linux, not distro specific packages.