[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[bug#49238] [PATCH v1 2/2] gnu: Add ytfzf.
From: |
Raghav Gururajan |
Subject: |
[bug#49238] [PATCH v1 2/2] gnu: Add ytfzf. |
Date: |
Mon, 5 Jul 2021 08:03:53 -0400 |
Hi Maxime!
That's a neat trick to avoid fragile (substitute* ...).
However, as I understand it, the origin is meant to be
usable as source code (think install dependencies && guix build && tar xzf
stuff.tgz
&& ./configure && make && try it out), such that
"guix build --source=transitive stuff" would give all the
source code for building stuff (in the sense of ‘Corresponding Source’
of the GPL), and "guix-mpv", 'guix-jq" ... don't exist anywhere.
I don't know if that has been spelled out somewhere though.
I'd suggest adding "patch" to 'native-inputs', adding the patch
to 'inputs' or 'native-inputs' (doesn't really matter which) and
doing (invoke "patch" OPTIONS "blabla.patch") before the substitute*.
Actually, myself I'm not convinced because you could consider
the package definition itself to be part of the ‘corresponding source’.
I get the idea, but I don't think we can call .patch files inside
phases, the patches directory is not exposed/available inside
build-environment.
I'm wondering if (string-append (assoc-ref inputs "catimg") "/bin/catimg")
would be better, as 'string-append' is less complex than 'format'
and "format" doesn't seem to provide any additional value here.
Cool! I have made this change in v4.
Now about the patch:
Maybe tell people to report issues at bug-guix@gnu.org or #guix? Dunno
Changed in v4.
Don't forget to patch 'column'.
Don't forget to patch "mkfifo".
Don't forget patching 'sleep'. It is not shell a built-in
(try "type sleep" and "type [" in a terminal").
Don't forget patching 'grep' and 'tr'.
Don't forget 'grep -> guix-grep' and 'cut -> guix-cut'
Don't forget 'awk -> guix-awk' and 'sort -> guix-sort' and 'uniq -> 'guix-uniq'
Don't forget 'sed -> guix-sed' and 'awk -> guix-awk'
Thanks, I have patched these in v4.
FWIW, writing to "/tmp/ytfzf" seems to be a potential security problem
and bad behaviour on multiple-user systems.
What would happen if /tmp/ytfzf is a symlink to /etc/passwd an ytfzf is run
as root (yes, running as root is not recommended)? Would that brick the system?
What if /tmp/ytfzf is a symlink to ~/.profile? Would that brick the login?
What if multiple users run ytfzf concurrently? Would they overwrite eaech
other subtitles? Would a different user be able to see what the other
is downloading?
A relatively easy fix would be to write to, say, $HOME/.cache/ytzf-subs
instead (not sure what the proper directory would be), which is completely
under the user's control.
Good catch. I have changed this in v4.
Let me know if v4 looks good.
Regards,
RG.
OpenPGP_signature
Description: OpenPGP digital signature
- [bug#49238] [PATCH v1 2/2] gnu: Add ytfzf.,
Raghav Gururajan <=