Re: Flatpak prevents mex linking to any system libraries

[Richard Crozier]

On 09/07/18 19:04, Mike Miller wrote:

> For your definition of "system libraries", which I'm assuming is not the
> same as my definition. I will continue assuming you mean "a particular
> mathematical or scientific library which is not part of a standard
> operating system installation."


Yes, sorry, I mean any libraries in /usr/* which is not accessible to 
the Octave Flatpack version.


> This is more of a Flatpak question than an Octave question.
>
> The question could be worded as, how does Flatpak plan to accomodate
> applications that allow dynamic loading of plugins or extensions that
> may depend upon other libraries that are not part of the Flatpak
> runtime?
>
> I am not a Flatpak maintainer so I can only guess, but my guess would be
> that they will expect the extension to download or bundle everything
> with it. This is similar to the typical Python pip module distribution
> model, where e.g. NumPy bundles copies of FFTPACK and LAPACK, and PyQt5
> bundles a copy of the entire Qt 5 runtime.


ok I had a look and found some things about extensions:

https://github.com/flatpak/flatpak-docs/issues/18

This might work for forge packages where you know the package exists in 
advance, but still doesn't help with user-built mex or oct files which 
link to libraries in /usr/*


> > The only alternative (since the ppa is no longer to be updated)
>
> That is not true, the PPA will be updated when Octave 4.4 is in Ubuntu.
> But I do hope that most users will find the Flatpak app to be a viable
> solution for their use case, when they care more about using Octave and
> less about integration with the operating system.


ok, sorry, I misunderstood some earlier correspondence on this. The 
thing is, lots of forge packages use libraries from /usr/local, e.g. 
odepkg, netcdf etc. Basically anything that provides an interface a C++ 
library for Octave. I think typical users will have an expectation of 
using these packages, rather than just bare Octave.


> > is to
> > install Octave from source which is daunting for typical users.
>
> That's not the only alternative. You can install or copy the libraries
> needed into a user's home directory, or you can bundle the libraries
> with the mex or oct code.


This has problems because you can't easily build portable libraries on 
Linux, mainly due to libc, so users would have to build them, or I would 
have to do the copying on the user's system in a script or something, 
which seems likely to break, and become complex depending on library 
versions etc. It also means these libraries won't be updated with, e.g. 
'apt upgrade' since they're just a copy in some random location.


> If it is a typical numeric library, it should be easier to build and
> install that in a user's home directory than to build and install Octave
> from source.


ok but that starts to get seriously complicated, for example I have a 
project which uses the mbdyn, the gnu scientific library, and f2c. I 
don't really fancy making my users find, download and build all of 
these. I already make them install MBDyn, which is painful enough.


> Or you can try building your own Octave package for Ubuntu using the
> Debian source package, to try to get ahead of the Ubuntu maintainers.


I think my solution will be to create bash install scripts for each 
flavour of Linux I choose to support and point users to them, maybe I'll 
also put them on the Octave wiki. This is not ideal, but I suppose my 
real issue is that I require Octave 4.4 rather than 4.2 which what is 
commonly available in package repositories.

Regards,

Richard

--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.