unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: "Clément Lassieur" <clement@lassieur.org>
To: Ricardo Wurmus <rekado@elephly.net>
Cc: 30728@debbugs.gnu.org
Subject: bug#30728: guix-install.sh doesn't work if run with "sudo"
Date: Sat, 31 Mar 2018 00:07:45 +0200	[thread overview]
Message-ID: <87efk1jjym.fsf@lassieur.org> (raw)
In-Reply-To: <87o9j7dwjt.fsf@elephly.net>

Hi Ricardo,

Ricardo Wurmus <rekado@elephly.net> writes:

> Hi Clément,
>
>> I am surprised that you didn't comment on
>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=30728#32 (where I explain
>> to you why I disagree with Guix being installed in ~root) before saying
>> LGTM.
>
> Don’t be surprised: there are too many emails and I’m bound to forget
> about some.  My apologies for not repyling to your email earlier.

Thank you for your reply. :-)  I definitely understand.

> I read your mail but I disagree with the conclusions.  It is not the job
> of the installer script to install Guix for a particular user.  It is
> for a site-wide installation, including the set up of the daemon and a
> service script.  These things must happen as root.  The idea is that
> Guix is installed for the whole site and made available to all users.

The installation must happen with root privileges, but that doesn't mean
that Guix should be installed in ~root, because root is a particular
user.  See http://www.linfo.org/root.html:

    "/root contains configuration files for the root account, just as
    each ordinary user's home directory."

Thus I don't think things in ~root should be site-wide, and I have never
seen such things.  Site-wide stuff is usually in /var, /etc, etc.
(Which is not what I'm asking for, but in the long term it would be
better, in my opinion.)

> Individual users can then choose to use “guix pull” to control their own
> version of Guix.

And they will typically forget to update the daemon (and the site-wide
Guix).  Allowing a user to be responsible for updating Guix makes it
more likely to be updated.  Much more likely if the user doesn't need to
handle two different Guix installations.

> I consider it inelegant and dangerous to make the Guix installation of
> an unprivileged user the variant of Guix that is used by all users on
> the system.  Having it managed by the root user avoids surprises, even
> on single-user systems, because the implication is that changes to the
> root user’s Guix installation have system-wide effects.

I agree that those system-wide effects are not ideal, but I don't think
it's worse than the system-wide effects from ~root.  The implication you
are talking about isn't obvious to me, because root is a user as every
other, the only difference being its power.  Things root does shouldn't
have system-wide effects either.

And I wasn't asking to install Guix in the user's home, rather to let
them choose between two imperfect solutions.  In other words, to give
them more freedom.  For example if the user does 'sudo -E
./guix-install.sh', Guix would be installed in their home, whereas if
the user does 'sudo -H ./guix-install.sh', Guix would be installed in
~root.

Your script is very useful anyway, thank you for it!

Clément

  reply	other threads:[~2018-03-30 22:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87zi3lh6mb.fsf@lassieur.org>
2018-03-23 13:20 ` bug#30728: guix-install.sh doesn't work if run with "sudo" Clément Lassieur
2018-03-25  5:16   ` Chris Marusich
2018-03-26  8:05     ` Clément Lassieur
2018-03-26  9:18       ` Marius Bakke
2018-03-27  7:46       ` Ricardo Wurmus
2018-03-27  9:11         ` Clément Lassieur
2018-03-27 16:08           ` Chris Marusich
2018-03-28 19:24             ` Ricardo Wurmus
2018-03-29  5:07               ` Chris Marusich
2018-03-29  8:26                 ` Clément Lassieur
2018-03-29  7:48               ` Clément Lassieur
2018-03-29 10:07                 ` Ricardo Wurmus
2018-03-30 22:07                   ` Clément Lassieur [this message]
2018-03-29  8:04             ` Clément Lassieur

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87efk1jjym.fsf@lassieur.org \
    --to=clement@lassieur.org \
    --cc=30728@debbugs.gnu.org \
    --cc=rekado@elephly.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).