IRC channel logs

<efraim>I got a request for julia-1.9 so I'm back to working on that

<efraim>I pretty much have a working build, but apparently now it expects to be able to dlopen everything, so looks like I'll get to wrap the julia binary with a bunch of stuff :/

<jeanjack>hello there :) Now that debian stable comes with a "usable" guix, I'm looking to use it for my cluster.

<jeanjack>Till now, I always been installing stuff globally for my users. I think on the way guix is made, there is no option to install package on /usr/local/ and it rely on profile

<jeanjack>is it something known and documented to make all users having the same profile ?

<nckx>Hi jeanjack! Feel free to repeat your question in #guix for a wider audience. Iff you like.

<jeanjack>Okay

<jeanjack>but it isn't a common use even for clusters to keep an admin that provide the package ?

<efraim>I got used instead to continually package new packages and fix guix mistakes others made

<rekado>jeanjack: in the early days of our cluster installation at the MDC I would maintain shared profiles

<rekado>at first it was a single profile for the whole institute

<rekado>then profiles for individual groups

<rekado>until we just gave up on that and let everyone have their own profile

<rekado>like efraim wrote, adding and fixing packages it really the most important part of maintaining a shared installation

<rekado>for projects we use manifests and channel files to be sure that everyone uses the exact same software

<rekado>but there’s little value to enforcing the same software across the whole institute

<jeanjack>efraim: sorry I wasn't clear, I was speaking more about installing the packages when i said 'provide package'

<efraim>jeanjack: I assumed that's what you meant. With guix taking care of user installed packages and profiles per esoteric package, they still needed someone to sort out actually packaging some of the monstrosities they wanted to use

<jeanjack>But, if many users need the same package, they will be an installation for each profile ?

<jeanjack>efraim: I know that feeling :)

<efraim>we maintain a fall-back profile that gets bumped like twice a year and mostly remind people that we're happy to take requests and they're responsible to make sure it actually works

<efraim>I think I had to hardcode a key into one of the packages and then make a wrapper to read the key and then set $HOME back to what it was

<efraim>we sometimes passed a profile around but generally everyone installed the software when they wanted it

<efraim>between the deduplication of files in the store and anything installed in a profile being protected from garbage collection there didn't seem to be a lot that went wrong, especially with it being terminal only

<jeanjack>Ok, so the hash-package-version with same package-version but different hash are just folders/link ? It didn't looked like deduplicated to me

<efraim>I haven't looked too closely because the store on my computer is like 500GB, but I think of it as everything actually lives in /gnu/store/.links and is hardlinked to its real location

<jeanjack>for now I'm more thinking about a strategy with a /gnu/store/hash-profile/bin in everyone's path, and everyone free to install on their own profile on a "natural guix" way

<efraim>so file-level deduplication

<jeanjack>efraim rekado thanks a lot for your pointers, i'll do some more testing and mostly more readings to sort things out :)

<efraim>oh, people really really want to install guix itself, keep telling them not to :)

<rekado>jeanjack: you probably shouldn’t have literal /gnu/store/… directories on the PATH, because you won’t be able to just update them. For shared profiles I used “guix package -p /usr/local/shared-guix-whatever/.guix-profile” to install to the shared prefix. Then you can treat /usr/local/shared-guix-whatever as a regular old prefix tree.

<rekado>the /gnu/store locations are implementation details; they really aren’t meant for users to interact with them.

IRC channel logs

2023-07-31.log