Details
- Reviewers
DataDrake JoshStrobl - Group Reviewers
Triage Team - Maniphest Tasks
- T8840: Broot
- Commits
- R4976:406edbdcd729: Initial inclusion of Broot, resolves T8840
- Build Package
- Install Package
- Run "Broot" in multiple directories
- Use all functions such as opening files, search for files, and opening other directories
Diff Detail
- Branch
- master
- Lint
No Lint Coverage - Unit
No Test Coverage
Event Timeline
You can add to "Summary": Resolves T8840
arc diff --edit to do that
This will link the "broot" task with this diff.
Is there a reason for using a binary from a third-party repo instead of building it ourselves?
Regarding what @EbonJaeger said, I think it would be much better to use the actual tarball releases over at https://github.com/Canop/broot/releases and build it ourselves. I don't think the current implementation will be accepted unless there is a very specific reason and especially not when the binaries come from someone else than the project owner...
@EbonJaeger @Jacalz The repository is actually mine on github. The binary comes from official site here. All I did was create a makefile for the binary and create a repo for both on github in order to make it easier to package for multiple distros. If that is against any rules though, I was unaware, and I will work on a .yml based off the upstream tarball until we get word from the devs.
I am pretty sure it is. I think it more or less is due to security reasons. It is very hard to know if you tampered with the source or not. Having it built from official source code on the build server makes sure that it doesn't contain any nasty surprises.
We always build from source if source is available and there are no extenuating circumstance. I won't accept this unless you are building from these source: https://github.com/Canop/broot
| package.yml | ||
|---|---|---|
| 13 | description should go after summary, not after builddeps. | |
| 18 | According to https://github.com/Canop/broot/blob/master/build.rs they are also building shell completions and I see a man page dir in the project's root. We should ideally be installing what shell completions they do have:
manpage location will be determined by the section they are expecting, probably 1 for general commands, so it should be installed to /usr/share/man/man1/ and be sure it has .1 appended to the end of the man page file name. | |
| package.yml | ||
|---|---|---|
| 19 | Seems like a fair bit of redundancy with how you're doing completions installation. You could more easily accomplish all of this using a pushd into the target out directory and loop a list of the completions or the directories and install from there. Otherwise it's a good start. | |
I'll be honest, I don't really know how to use pushd commands, and even after reading manpages and articles I couldn't really understand it. I cut the install commands by half though by using the -t operand. Hope it works
There is still something to do.
move description from here:
builddeps :
cargo
description: |
A new way to see and navigate directory trees using cd, tree, and fuzzy search.
build : |
cargo build --release --lockedto here
summary : A new way to see and navigate directory trees
description: |
A new way to see and navigate directory trees using cd, tree, and fuzzy search.
networking : yes