Re: Bug#952927: [live-build] inconsistency and unnecessary complexity in bin checking
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.
Reply to: