bug#22695: Binary Installation bugs and suggestions

[myglc2]

Ricardo Wurmus <address@hidden> writes:

> myglc2 <address@hidden> writes:
>
>> I attempted to perform 'Binary Installation' on Debian 8 following ...
>>
>> https://www.gnu.org/software/guix/manual/html_node/Binary-Installation.html#Binary-Installation
>>
>> last updated November 04, 2015
>
> I suggest looking at the latest version of the manual in the repository
> when using the latest version.  In a related bug report I already
> commented that I think it would be good to host the latest version of
> the manual on the website.

Sounds good. How does a naive user trying to install Guix for the first
time do that?

>> Bugs:
>>
>> A) The 4 occurrences of '~root' should be replaced with '/root'
>
> This is equivalent.  In bash “~root” expands to the home directory of
> the root user, which usually is “/root”.

Ninja trick. Did no know. Does it apply in non-bash shells?

>> B) What does 'On hosts using the systemd init system, drop
>>    /root/.guix-profile/lib/systemd/system/guix-daemon.service in
>>    /etc/systemd/system.' mean.
>>
>>    FWIW, I tried ...
>>
>> cp /root/.guix-profile/lib/systemd/system/guix-daemon.service \
>>    /etc/systemd/system/guix-daemon.service
>>
>> ... which did not work.
>
> How did it “not work”?  Dropping the file there does not start the
> service automatically.  You’ll need to reload the service definitions
> and then actually start the service.  But that’s really systemd
> knowledge, and I don’t think it belongs in the Guix manual unless it’s
> really short.

"Thompson, David" <address@hidden> writes:
[...]
> What didn't work, exactly?  I've personally done this on systemd
> setups and it works fine.

When I reboot my Debian 8 server, guix-daemon is not running.

IMO, the Guix story is most appealing to a user at this point in time.
So you want to help a user-level person try out Guix on a machine they
happen to have root or sudo on. If you force them go off and learn all
about systemd they may well run out of gas and never insall Guix.

So I think you should tell them specifically how to make guix-daemon be
running after a reboot, or they will be reporting that as a bug.

>> Suggestions:
>>
>>  1)'guix archive --authorize < 
>> /root/.guix-profile/share/guix/hydra.gnu.org.pub'
>>
>>    ... produced ...
>>
>>    'warning: failed to install locale: Invalid argument'
>>
>>    It is not good that the first guix operation that root attempts
>>    throws a warning.  Apparently this is to be expected, as careful
>>    study of '2.6 Application Setup' might suggest.  As a minimum, we
>>    should advise root that the warning is expected.
>
> I wonder why we get this error in the first place.  I’d rather eliminate
> the error than tell people to ignore it.
>
> Any ideas what causes it?

"Thompson, David" <address@hidden> writes:
[...]
> This warning is unavoidable when the glibc on the host distro has
> locales that our incompatible with the glibc that Guix uses.  It's
> unfortunate, but *much time* was spent dealing with this headache
> already, including time spent talking to glibc developers.

The instructions should acknowledge that the warning may occur and can
safely be ignored.

>> 2) 'And that’s it! For additional tips and tricks, see Application
>>    Setup.' should be changed to say something like, 'This completes
>>    root-level install of Guix, However each of your users will need to
>>    first set their Locales and, if they intend to use X Window system,
>>    X11 fonts, as described in '2.6 Application Setup' before Guix will
>>    be fully functional.
>
> That sounds mostly fine, but I don't understand the X11 fonts part.  I
> use Guix on foreign distros and have no such issues regarding fonts.

My experience as a user of research GNU/Linux systems adminstered by
multiple people in multiple organizations is that fonts are all over the
map and a major pain. If Guix provides an out-of-the-box reproducible
X11 font experience that would be a fantastic feature for users like me.

But maybe it is unnecessary to specifically install X11 fonts?

If I install emacs, will it drag in the Guix X11 font set used to build
it?

Ricardo Wurmus <address@hidden> writes:
[...]
> The first item in the “Application Setup” section is about locales.  I
> think it is sufficient the way it is now.  The section in question is
> about how to install Guix.  Locales and X11 fonts are not required to
> use Guix.

OK, but I don't think you want your users seeing recurrent warnings. IMO
it would be better to advise them to install locales than to let them
see a warning on every guix operation.

>> 3) Is it possible for root to pre-configure locales and X11 fonts for
>>    users?
>
> Only by traditional means: installing “glibc-locales” in a shared
> location and augmenting /etc/profile to set GUIX_LOCPATH.  This is not
>

"Thompson, David" <address@hidden> writes:
[...]
> They would have to modify that user's package profile and
> .bash_profile, which I don't think we would want to recommend.

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?

>> 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.

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.

> Building the binary is only really useful when hacking on a git
> clone of the repository.  It’s only mentioned there to show that the
> binary tarball isn’t special.  I do think it would be better to have
> this in a footnote or somewhere else where it doesn’t hurt the flow.

How about removing the tarball example entirely?

If I am sysadmin, I think a better thing to show me is how to build a
binary locally and see that, Yup, it matches the hydra substitute.

>> 6) Should a root 'guix pull' be recommended?
>
> Depends.  I think it’s not so useful as users other than root will be
> using Guix mostly.  For every Guix user “guix pull” (or installing from
> git) is recommended, so root is not special.

But doesn't root want/need to update guix?

>> 7) Given the "invasive" nature of this install, an uninstall script, or,
>>    as a minimum, explicit instructions of how to remove Guix, really
>>    must be provided.
>
> Guix doesn’t touch anything but /gnu, $prefix/etc/guix/acl, and
> $localstatedir.  It can be uninstalled by removing these files.  I agree
> that adding this information to the manual would not hurt.

FWIW, I used locate to look around for Guix detritus and I ended up with
this in my makefile:

uninstall:
        -rm -fr /gnu
        -rm -fr /var/guix
        -rm -f /root/.guix-profile
        -rm -fr /etc/guix
        -rm -f /usr/local/bin/guix
        -rm  /etc/systemd/system/guix-daemon.service
        -rm -fr /var/log
        -rm -fr /root/.config
        # don't forget to kill guix-daemon!
                                                                        

>> 8) It seems unlikely that a typical sysadmin will be willing to install
>>    Guix following the instructions as they now stand. This might be
>>    addressed by providing a Guix package for popular distributions.
>
> 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'.

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'.

"Thompson, David" <address@hidden> writes:
[...]
>
> This has been mentioned many times, but does anyone actually want to
> step up and do the work?  Getting such packages into upstream distros
> is unlikely because Guix does not conform to the FHS, but we can
> provide the packages on our own website.
>
> Personally, I feel that the instructions are so few that it's easy to
> do by myself and it also informs me about what exactly is going on
> with my system.

Agreed, when using my home servers. But a sysadmin with only a few hours
to understand Guix and many users potentially impacted will be much more
jumpy about the Guix install.

>> 9) We leave the root user with no locales or X11 fonts.  Do we recommend
>>    this?
>
> Again, I don't understand the X11 fonts part, but this problem only
> happens when the host distro uses a glibc with incompatible locales.

e.g. Debian and what else?

Ricardo Wurmus <address@hidden> writes:
[...]
> I hardly ever use the root user’s Guix profile when using Guix on a
> foreign distribution.  I don’t think root needs X11 fonts as it isn’t
> supposed to have its own X session.

OK, this may be a canard. I was thinking that a user might use X as root
running directly on a machine (which I don't do). Sorry.