Running guix package manager on sfos?

asked 2019-10-13 13:56:01 +0300

szopin gravatar image

Has anyone tried it? They have armhf binary release that should in theory work, but bit worried about space as root partition is small enough as it is (symlinking /gnu/store to somewhere in home partition might possibly work? The option to install packages to user's home directory sounds pretty cool too in this context). Anyone has any experience with this they could share?

edit retag flag offensive close delete

Comments

1

Speaking of packages installed without root in /home (or even.an.SD card):

miniconda is available on arm7l, too thanks to the popularity of Rasberry Pi 2/3/4

DrYak ( 2019-10-14 15:06:08 +0300 )edit

Also nix has arm support, I wonder if this wouldn't help with all the packages that require newer Qt, as both guix and nix support installing multiple versions of libs, so in theory one could provide Qt 5.13 libs if they have features they need, without touching the 5.6 (or 5.9 we'll get in 2020) ones used by base system (at least that's supposed to be possible in theory?)

szopin ( 2019-10-14 15:19:37 +0300 )edit
1

Even without going into using an unusual package management system, nothing prevent somebody on openrepos.net making a pretty standard RPM of Qt 5.13 version that installs inside /opt/lib, and Qt applications that require 5.13 having special "Requires" and using an RPATH that taps into the correct version.

(Been there done that as part of a past job on research clusters)

DrYak ( 2019-10-14 17:13:06 +0300 )edit

@DrYak any way to do it with this? https://openrepos.net/content/llelectronicsdev/qtwebkit-5212-dev It currently requires overwriting system libs and restoring them before system update so was hesitant, trying to ld_library_path and ld_preload before running webcat doesn't seem to work. As both nix and guix are in theory capable of being run on top of any distro thought would be worth trying (then again phones are probably still not good enough in terms of storage to keep all the previous libs/binaries)

szopin ( 2019-10-14 17:56:34 +0300 )edit
1

An RPATH is basically something like a LD_LIBRARY_PATH burned into an elf executable.

The problem is that these only change the path searched when looking for .so files when starting a program. It won't change any mention of path hardcoded into the files themselves (e.g.: the path where the Qt libraries look to load plug-ins).

For that to work more reliably, you would need to ask LLelectronics to make a separate different version of the Qt libraries designed to install into /opt (and check if there aren't any remaining references to /usr/lib).

And then either try running Webcat with LD_LIBRARY_PATH / with patching the RPATH using patchelf, or ask LLelectronics to make a separate different edition of Webcat that is pre-baked with the correct RPATH and has the 'opt' version of Qt as a hard-requirement for installation.

And still, some tracing (e.g.: with ltrace) to make sure webcat loads everything from opt would help. You could even start now to check what your jury-rigged LD_LIBRARY_PATH solution is loading from the wrong path But such tracing would even need to be done to validate a hypothetical solution by LLelectronics..

DrYak ( 2019-10-14 19:36:33 +0300 )edit