On Thu, 2020-03-12 at 11:50 +0900, John Crawley wrote:
On 2020-03-12 11:41, jnqnfe@gmail.com wrote:
On Thu, 2020-03-12 at 11:11 +0900, John Crawley wrote:
On 2020-03-02 07:12, jnqnfe@gmail.com wrote:
Package: live-build
Version: 1:20191221
Owner: jnqnfe@gmail.com
Severity: minor
there are lots of checks being done that tools are available
and
executable. this is done with a mixture of use of `which` and
fixed
paths, redirection of output to /dev/null (`2>/dev/null`) and
redundant
executability tetsing on top of `which` checks (which already
does
such
a check).
this can be tidied up and robustified.
- we can move everything to `which` and drop fixed paths,
thus
robustifying things should a bin every move (you never know).
- we can drop performing pointless `-x` testig on top of
`which`
use,
since `which` already performs this and signals such in its
exist
code
(returns 1 if nonexistant or nonexecutable).
- we can drop the `2>/dev/null` redirection which in my
testing
seemed
to make no difference.
proposal: switch to conditionals of the form:
```
if [ $(which dpkg) ]; then
#whatever
fi
```
The use of 'which' is not universally regarded as robust:
depending
on
the environment it can return true even if the executable does
not
exist, and may also output an error message, breaking the above
test.
oh really. that's disappointing :/
POSIX has 'command -v <command>' which should work under the
#!/bin/sh
shebang that live-build scripts use:
if command -v dpkg >/dev/null
then
echo "we have dpkg"
fi
See: https://mywiki.wooledge.org/BashFAQ/081
yeah I actually came across the `command -v` solution a few days
ago
but with the `which` based solution already in place saw little
value
in reworking it. if `which` is flakey though, then perhaps its
important that we do change.
i've got rather a lot of stuff still to work on on live-build
already
never mind anything else. would you have time to submit a patch
yourself?
Time, yes probably, but I'm not a Debian developer, just a user (of
live-build too) and - rightly - don't have write access to the repo.
If, given that status, there's anything I can do which would help,
please say. Does salsa support "pull requests" ala GitHub?
I'm not a DD either, nor have my own access rights to the official
repo, I'm just making a lot of contributions currently.
yes, you can create an account on salsa (which is a Debian hosted copy
of gitlab), you can use your existing gitlab (or even github i think)
credentials for this. you can then fork, create a branch, create a
commit, push the branch to your salsa fork, then create a merge request
on the official Debian Live repo and someone will take a look. it's a
hell of a lot nicer than emailing patches as I was doing back in 2015,
the last time i worked on live-build.