octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Build a portable linux binary?


From: Mike Miller
Subject: Re: Build a portable linux binary?
Date: Sat, 23 Feb 2019 11:55:56 -0800
User-agent: Mutt/1.10.1 (2018-07-13)

On Sat, Feb 23, 2019 at 09:06:06 +0000, CROZIER Richard wrote:
> As someone else has pointed out though, actually for me the problem is
> that even the latest OS, e.g. Ubuntu 18.04 has an out of date Octave
> package in the repositories. For me, I routinely build Octave from
> source,

Is there anything we here can do as a community to help counter this
belief that Octave from Ubuntu LTS is "out of date"? It's a relative
term. Compared to Octave 3.2, Octave 4.2 is an amazing improvement.

If I have a system with Ubuntu 16.04, which is old but still supported,
I will get Octave 4.0. If I just want Octave, I probably don't care that
it's 4.0, so it's not "out of date" to me, it works perfectly fine. I
will also get GNOME 3.18 and LibreOffice 5, which also work perfectly
fine even though they are not the bleeding edge latest release.

"Stable" distributions will always have applications that are years
behind what developers are working on now, that's how the distribution
model works.

> but if I want people to use stuff which uses the latest(ish)
> features, they have to build Octave too. Remember this is *hard* for
> ordinary users who don't even know about make for example.

I agree, ordinary users should absolutely not be building Octave from
source, unless they want to.

Ordinary users should be installing Octave from some kind of package
manager (apt, dnf, yum, brew, flatpak, snap), or possibly a package
manager inside a chroot, container, or virtual machine. Many viable
options easier than building from source.

Users should absolutely not be downloading some binary tarball from a
web site to install Octave (or any other application).

> The Flatpak solution
> would be great, if it didn't stop Octave packages linking to non Flatpak
> libraries.

I read this is as: the Flatpak solution is great, unless you need to
install one of a small number of Forge packages that depend on
third-party system libraries, right?

I fully support the Flatpak package, and this seems like a niche
objection to me. If it's an important problem to you, can you help? Can
you document which packages don't install because of unavailable system
libraries?

If I maintained a package that linked with, let's say the Speex library,
then I would probably bundle the speex source with my package so it is
downloaded and built inside the package instead of relying on system
libraries.

-- 
mike

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]