PKGBUILD review request: as-tree

donbex · 2020-07-26 21:14:34

# Maintainer: donbex <ap dot m at runbox dot com>
pkgname=as-tree
pkgver=0.12.0
pkgrel=1
pkgdesc="Print a list of paths as a tree of paths"
arch=('x86_64')
url="https://github.com/jez/as-tree"
license=('custom:BOML')
#depends=()
makedepends=('cargo')
#checkdepends=()
source=("${pkgname}-${pkgver}.tar.gz::https://github.com/jez/${pkgname}/archive/${pkgver}.tar.gz")
md5sums=('77cf5584fced10b16c53ccb4c25224f7')

prepare() {
	cd "$pkgname-$pkgver"
  # Update the lock file. Shouldn't be needed with releases after v0.12.0.
  sed -i "s/version = \"0.11.1\"/version = \"${pkgver}\"/" Cargo.lock
}

build() {
  cd "$pkgname-$pkgver"
  cargo build --release --locked --all-features --target-dir=target
}

package() {
  cd "$pkgname-$pkgver"
  install -Dm 755 target/release/${pkgname} -t "${pkgdir}/usr/bin"
  install -Dm 644 LICENSE.md "$pkgdir/usr/share/licenses/$pkgname/LICENSE.md"
}

There are some tests as well, which depend on bazel but I couldn't manage to run them (see the project's readme).

Last edited by donbex (2020-07-27 01:36:13)

twelveeighty · 2020-07-26 22:14:07

Post it using code tags, not quote tags.

I don't know/use Rust, but it appears to have its own dependency management, which means you have to be extra careful with building packages. Where are the deps that "cargo" pulls in stored? If they get pulled into either your home folder or the pkg folder, that could be bad news.

Also: shouldn't the depends array have 'rust' in it instead of makedepends having 'cargo'? I checked a random Extra package (maturin) that depends on rust and it has similar build() and package() functions, so I assume that's how the deps work for rust packages?

Trilby · 2020-07-26 23:48:21

Out of curiosity, what does this software do that isn't provided by just piping to `tree --fromfile=.`?

donbex · 2020-07-27 01:35:47

twelveeighty wrote:

I don't know/use Rust, but it appears to have its own dependency management, which means you have to be extra careful with building packages. Where are the deps that "cargo" pulls in stored? If they get pulled into either your home folder or the pkg folder, that could be bad news.

I had some past experience with similar systems creating Haskell packages for myself in the past, so I already checked the Cargo.toml file before creating the package, which includes a list of dependencies, which were minimal. Now that I look more closely, it could be possible that they are not part of the standard library as I assumed.

Also: shouldn't the depends array have 'rust' in it instead of makedepends having 'cargo'? I checked a random Extra package (maturin) that depends on rust and it has similar build() and package() functions, so I assume that's how the deps work for rust packages?

The wiki guidelines for Rust packages point to ripgrep and cbindgen as example PKGBUILDS, both of which include cargo but not rust (which provides cargo). Furthermore, neither seem to include the Rust dependencies of those packages (cfr. the Cargo.toml of ripgrep).

From the output of ldd on the compiled binary, the only runtime dependency that I might have missed is gcc-libs, which I omitted since it's pulled in by gcc, which is part of the base-devel group.

$ ldd /usr/bin/as-tree
	linux-vdso.so.1 (0x00007ffc1ed8f000)
	libc.so.6 => /usr/lib/libc.so.6 (0x00007f077c139000)
	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f077c117000)
	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f077c111000)
	libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f077c0f7000)
	/lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x00007f077c385000)

Trilby wrote:

Out of curiosity, what does this software do that isn't provided by just piping to `tree --fromfile=.`?

Not much, apparently. I found as-tree through fd; I wasn't aware of tree and I assume that there wasn't a pre-existing solution.

Edit: A quick benchmark suggests that as-tree is a little faster than tree, but not enough to justify by itself a separate tool.

$ wc -l ls.list
84758 ls.list

$ hyperfine --warmup 3 'cat ls.list | tree -C --fromfile .' 'cat ls.list | as-tree'
Benchmark #1: cat ls.list | tree -C --fromfile .
  Time (mean ± σ):     571.0 ms ±   5.6 ms    [User: 571.4 ms, System: 32.9 ms]
  Range (min … max):   562.2 ms … 580.9 ms    10 runs

Benchmark #2: cat ls.list | as-tree
  Time (mean ± σ):     454.3 ms ±   7.8 ms    [User: 349.1 ms, System: 131.4 ms]
  Range (min … max):   443.1 ms … 471.9 ms    10 runs

Summary
  'cat ls.list | as-tree' ran
    1.26 ± 0.02 times faster than 'cat ls.list | tree -C --fromfile .'

Last edited by donbex (2020-07-27 01:50:43)

Raynman · 2020-07-27 09:29:04

twelveeighty wrote:

Also: shouldn't the depends array have 'rust' in it instead of makedepends having 'cargo'? I checked a random Extra package (maturin) that depends on rust

The package description says that maturin is a (development) tool to build and publish crates, so it would likely need tools like cargo at runtime.

donbex wrote:

From the output of ldd on the compiled binary, the only runtime dependency that I might have missed is gcc-libs, which I omitted since it's pulled in by gcc, which is part of the base-devel group.

base-devel packages can only be omitted from makedepends, not (runtime) depends.

eschwartz · 2020-07-27 12:29:28

But gcc-libs is, like glibc, directly required by the base metapackage.

Trilby · 2020-07-27 13:07:32

Base packages are not an exceptions from being listed in dependencies.

eschwartz · 2020-07-27 13:13:24

1) Yes they are.

2) Then people should stop complaining that this package fails to depend on gcc-libs. Start complaining that it fails to depend on glibc. (Ignore the fact that it's non-viable to have a linux OS with no libc.so, except for distros which are carefully built using static linkage for everything, and that's very much the exception.)

Last edited by eschwartz (2020-07-27 13:19:07)

Trilby · 2020-07-27 13:19:07

1) No they arent. This is productive isn't it. Base-devel is explicility listed as an exception in the packaging standards. Base is not:

wiki wrote:

Package dependencies
- Do not rely on transitive dependencies in any of the PKGBUILD#Dependencies, as they might break, if one of the dependencies is updated.
- List all direct library dependencies. To identify them find-libdeps(1) (part of devtools) can be used.

It says list ALL, not list some.

2) I didn't complain about either one. But whichever library(s) it depends on should be listed in depends.

3) You may want to change the packaging standards, and you may be in a position to do so. But until that is done, base packages should still be listed. Personally I think interstate highway speedlimits in the US are rather silly. I think they should be adjusted. But until they are changed, I can't claim it is legal to go 65mph in a 60mph zone. I may do it anyways, but I can't claim it's within the rules as the rules are clear.

4) The logic that you are using that we can assume / infer that glibc or anything else must be installed because of other things that are clearly installed is explicitly rejected as invalid in the published packaging standards as quoted above: Do not rely on transitive dependencies.

Last edited by Trilby (2020-07-27 13:33:10)

Arch Linux

#1 2020-07-26 21:14:34

PKGBUILD review request: as-tree

#2 2020-07-26 22:14:07

Re: PKGBUILD review request: as-tree

#3 2020-07-26 23:48:21

Re: PKGBUILD review request: as-tree

#4 2020-07-27 01:35:47

Re: PKGBUILD review request: as-tree

#5 2020-07-27 09:29:04

Re: PKGBUILD review request: as-tree

#6 2020-07-27 12:29:28

Re: PKGBUILD review request: as-tree

#7 2020-07-27 13:07:32

Re: PKGBUILD review request: as-tree

#8 2020-07-27 13:13:24

Re: PKGBUILD review request: as-tree

#9 2020-07-27 13:19:07

Re: PKGBUILD review request: as-tree

Board footer