~whereswaldon/arbor-dev

2 2

Re: [PATCH sprig] Add install script and resources to linux build

Details
Message ID
<CAHBARKc-s+VtYppiqOoDHLOL1Q65Ht9ng5yMzU69Tako8iUQ_Q@mail.gmail.com>
DKIM signature
pass
Download raw message
> > +LINUX_FILES = $(LINUX_BIN) ./desktop-assets ./install-linux.sh
> > ./appicon.png
>
> I wonder whether we shouldn't also include the license? Eventually, I'd like
> to bundle together the licenses of all of our dependencies as well, but that's
> sufficiently complex that it can wait.

That's a good idea. I'll add that in.

> > +PREFIX=${PREFIX:-${XDG_DATA_HOME:-$HOME/.local/share}}
> > +BIN_PREFIX=/usr/local/bin
>
> Why not install into $PREFIX/bin? I think that's the conventional behavior.
> I can understand why you might be reluctant to do that because ~/.local/bin
> likely isn't in $PATH for your desktop environment, but I suspect that the
> proper fix is to symlink from /usr/local/bin instead of putting the
> application there. I'd prefer that users didn't need to run the installer
> as sudo unless they modify the PREFIX to be a global install.

The main reason I didn't put it in XDG_DATA_HOME was because it wasn't
in my path, and that indicated to me that it is likely not in everyone's path.
From the specification XDG_DATA_HOME is for configuration. I definitely
agree that running the installation with sudo is not ideal, but if the install
script runs, exits cleanly, and the desktop file fails with no error message,
I would be more than a little confused.

I think there are a couple of options:
1. We can check if `~/.local/bin` is in PATH, and conditionally add a
   message recommending it added to the PATH. Thus notifying the
   user that the desktop file will not work out of the box.
2. We can prompt the user for a path to place the binary in, optionally
   invoking sudo if the directory is not owned by the user
3. Most application installations, or at least those installing desktop
   files, require sudo. While it isn't ideal, if someone is concerned
   about its use, the script is pretty straight forward. I think it is trivial
   to check this script for malintent due to its simplicity.

I don't know of a common, user-owned, PATH directory that we could
use. I personally use `~/bin`,
but I have also seen `~/.bin`. `~/local/bin`. and `~/.local/bin`. If
we want to refrain from using sudo
I think we should go with number 2, and let the user choose the path.
Otherwise I don't think sudo is terrible, considering the nature of
the script.

On Sat, Jul 4, 2020 at 7:56 PM Andrew Thorp <andrew.thorp.dev@gmail.com> wrote:
>
> Sorry, hit `tab` and `enter` in gmail's editor :facepalm:
>
> I think it is trivial to check this script for malintent due to its simplicity.
>
> I don't know of a common, user-owned, PATH directory that we could
> use. I personally use `~/bin`,
> but I have also seen `~/.bin`. `~/local/bin`. and `~/.local/bin`. If
> we want to refrain from using sudo
> I think we should go with number 2, and let the user choose the path.
> Otherwise I don't think sudo is a terrible, considering the nature of
> the script.

Re: [PATCH sprig] Add install script and resources to linux build

Details
Message ID
<C3YC7NYOK9BX.LRL6SER1QC1B@pop-os>
In-Reply-To
<CAHBARKc-s+VtYppiqOoDHLOL1Q65Ht9ng5yMzU69Tako8iUQ_Q@mail.gmail.com> (view parent)
DKIM signature
pass
Download raw message
> > > +PREFIX=${PREFIX:-${XDG_DATA_HOME:-$HOME/.local/share}}
> > > +BIN_PREFIX=/usr/local/bin
> >
> > Why not install into $PREFIX/bin? I think that's the conventional behavior.
> > I can understand why you might be reluctant to do that because ~/.local/bin
> > likely isn't in $PATH for your desktop environment, but I suspect that the
> > proper fix is to symlink from /usr/local/bin instead of putting the
> > application there. I'd prefer that users didn't need to run the installer
> > as sudo unless they modify the PREFIX to be a global install.
>
> The main reason I didn't put it in XDG_DATA_HOME was because it wasn't
> in my path, and that indicated to me that it is likely not in everyone's
> path.
> >From the specification XDG_DATA_HOME is for configuration. I definitely
> agree that running the installation with sudo is not ideal, but if the
> install
> script runs, exits cleanly, and the desktop file fails with no error
> message,
> I would be more than a little confused.
>
> I think there are a couple of options:
> 1. We can check if `~/.local/bin` is in PATH, and conditionally add a
> message recommending it added to the PATH. Thus notifying the
> user that the desktop file will not work out of the box.
> 2. We can prompt the user for a path to place the binary in, optionally
> invoking sudo if the directory is not owned by the user
> 3. Most application installations, or at least those installing desktop
> files, require sudo. While it isn't ideal, if someone is concerned
> about its use, the script is pretty straight forward. I think it is
> trivial
> to check this script for malintent due to its simplicity.
>
> I don't know of a common, user-owned, PATH directory that we could
> use. I personally use `~/bin`,
> but I have also seen `~/.bin`. `~/local/bin`. and `~/.local/bin`. If
> we want to refrain from using sudo
> I think we should go with number 2, and let the user choose the path.
> Otherwise I don't think sudo is terrible, considering the nature of
> the script.

How about this? Let's make PREFIX default to /usr/local/, which will
properly install everything globally (with sudo). The desktop file
can go in /usr/local/share/applications, the icon can go in
/usr/local/share/icons, and the binary can go in /usr/local/bin.

Then users who want a homedir install can override PREFIX to
~/.local/ if they want to (and they're probably used to managing
the PATH implications).

Re: [PATCH sprig] Add install script and resources to linux build

Details
Message ID
<CAHBARKdwfU-TfVe-kAOnOEE=MNufa6Fq1aqjSXOUCVU0CjGXhg@mail.gmail.com>
In-Reply-To
<C3YC7NYOK9BX.LRL6SER1QC1B@pop-os> (view parent)
DKIM signature
pass
Download raw message
That sounds good to me. I'll update the script and send out a new
patch set. :+1:
Export thread (mbox)