bug#22695: Binary Installation bugs and suggestions

[Ricardo Wurmus]

myglc2 <address@hidden> writes:

> The use case I had in mind is that sysadmin uses Guix to provide a
> specific Guix environment to support 1 or more "dumb" application users
> (e.g, provide a stable specific version of R to a project team for the
> duration of the project). In this case sysadmin does not want to burden
> the team members with learning Guix.
>
> Do we support such a case?

Yes.  I have been doing this for our cluster users for months before we
could make the changes in our environment that were needed to let users
manage their profiles by themselves.

We currently use Guix for shared per-group profiles, individual per-user
profiles, and per-project profiles.

You can install packages into a custom profile by using the “-p” flag,
e.g.

    guix package -p /path/to/shared/profile \
                 --install glibc-utf8-locales r r-genomation

Users would then have to add something like this to their
~/.bash_profile:

    eval $(guix package -p /path/to/shared/profile --search-paths=prefix)

or just add the result of the command in parentheses to the
~/.bash_profile.  This would prepend the “bin” directory of the profile
to the PATH and set other environment variables that are needed.

Then they could use an unchanging version of the “genomation” package
from within R, as defined in that profile.  (In the long run it would
make more sense to instantiate profiles using manifest files.)

Slightly off-topic: note that in this case installing R packages via
‘install.packages(...)’ is discouraged.  Some R packages link with
system libraries and unless you’re also adding the compiler toolchain to
your profile you would end up with binaries that are linked with the
system libc and thus cannot successfully be loaded by the R in your
profile, which is linked with libc from the Guix store.

I suggest going full Guix instead of mixing ‘install.packages(...)’ with
Guix stuff.  We have importers for CRAN and bioconductor, so packaging R
packages for Guix is usually really simple.  (I’ve used the importer to
generate package expressions for all of CRAN, but since I’m not using
them all I haven’t yet found motivation to submit patches for them.)

>>> 4) What do we mean by, 'The guix package must remain available in root’s
>>>    profile, or it would become subject to garbage collection—in which
>>>    case you would find yourself badly handicapped by the lack of the
>>>    guix command.'
>>>
>>>    What does root have to do to assure that 'The guix package remains
>>>    available'?
>>
>> I think this means that the root user should not uninstall guix with
>> guix.
>
> "Thompson, David" <address@hidden> writes:
> [...]
>>
>> Don't run 'guix package -r guix'.
>
> Cool, please say that.

+1!

> Ricardo Wurmus <address@hidden> writes:
> [...]
>>> 5) We should tell root how to verify that the installation was
>>>    successful.  If 'make guix-binary.system.tar.xz' is intended to do
>>>    this, we need to explain where to run it and how to verify the
>>>    result.
>>
>> The install was successful if “guix package -i hello” (or similar)
>> works.
>
> Cool, lets tell them to do that.

+1!

Would you be willing to send a patch?  (I’m pretty sure I’ll forget
doing this myself.)

>> Sysadmin here :) I installed it according to the instructions but also
>> expanded on them by setting up a shared store.  I’ll try to prepare an
>> RPM to simplify installation on distributions derived from Red Hat /
>> Fedora.
>
> Sorry, buy you really don't sound like 'a typical sysadmin'.

Oh, well :)

> In my experience, Mr. typical admin says, "if it's not in Yum or Aptitude I'm
> not going there". 
>
> A specific example, Mr. typical admin can not install the current
> release of package A because it is not in the production yum for the
> previous release of centos currently running. Mr. typical admin can not
> build the package from sorce because it would 'take too much time'
> and/or 'you are the only person asking for it'.

Heh, I think I know (an instance of) that person (template)!

I seem to remember that there’s an RPM for OpenSUSE somewhere, but I’m
not sure what the status is.  In my opinion it would be desirable to
have the .spec file to generate the RPM in the Guix sources.

~~ Ricardo