Arch Linux User Repository

PKGBUILD has experimental support for the aarch64 architecture since v10.0.0-2. Please report any errors in the comments below as maintainer do not currently own an aarch64 machine. Thanks.

@m040601 I believe I am following the package guidelines: https://wiki.archlinux.org/title/Arch_package_guidelines#Directories that talk about e.g.:

/usr/share/doc/pkg
/usr/share/licenses/pkg

where pkg is equivalent to $pkgname in the PKGBUILD file. By following that system, it is always easy to find the license or the documentation for a given package.

I do understand the logic behind your idea, but if we were following that system, it would be no easy feat to find the files beloging to a package without listing them all and seeing where they are located.

Unless there is unequivocal documentation for trimming the directory names, I feel it makes more sense to use $pkgname where the guidelines have pkg (which is exactly why all of my, currently 81, PKGBUILD files use that taxonomi — I didn't choose that indeliberately).

Cheers.

@m040601 Can you show me documentation for that, please?

@kseistrup

$ pacman -Ql docfd-bin

...
docfd-bin /usr/share/doc/docfd-bin/CHANGELOG.md
docfd-bin /usr/share/doc/docfd-bin/README.md
...
docfd-bin /usr/share/licenses/docfd-bin/LICENSE
...

The names of directories you create in "/usr/share/docs" and "/usr/share/licenses" dont get the "-bin" or "-git" suffixes appended.

It doesn matter if this PKGBUILD is called "XYZ-bin" or "XYZ-git".

It doesn matter if there is already, or there will be in the future, a PKGBUILD on the AUR called just "XYZ". Or one called "XYZ-git".

That's the job for other "tags" like for ex. "Conflicts", "Provides" "Replaces". So it should be,

/usr/share/doc/docfd/CHANGELOG.md
/usr/share/doc/docfd/README.md
/usr/share/licenses/docfd/LICENSE

@kseistrup Thanks for continuing to package this fairly niche piece of software : v

@m040601 Thank you for the kind words!

Re TUI: I agree it's ugly, but solving that essentially requires me to rework or add a lot of widgets to the underlying TUI library, which might be too much work for me.

Docfd has grown fairly complex in its architecture for real time interactive search with async UI, multithreading, DB handling, etc, to support the features I want, so TUI hasn't been the primary focus. Making it work on constrained systems took months of work and redesign as well. But I am interested in at least remediating the cumbersome part/usability issue.

If you are still using docfd and interested in discussing further, shoot me an email or open a discussion on github.

@m040601 Thanks for your encouraging words! :)

Thanks @kseistrup for the bin PKGBUILD. Perfect, with CHANGELOG and everything.

I'm curious about what for and how other Arch users are using it.

As an heavy CLI and TUI user, I've known and used the many other similar purpose "ripgrep-all" and "recoll". I like build indexes of my huge collections of research docs (plain, PDF etc) indexed. No daemons running, no complicated setups, no browsers involved.

I unexpectedly stumbled upon this tool today.

Gave it a quick try today. Ocaml ??? Cant comment on code quality. Very polished, succint, up to the point README and docs. Installed fine and ran flawlessly. Straight and easy to quickstart indexing. Seems speedy and performant on old hardware. No bugs seen.

Personally, on first impressions, I find the TUI usable, but a bit ugly and cumbersome. Understandable but still needs polishing.

Still testing.

PKGBUILD has experimental support for the aarch64 architecture since v10.0.0-2. Please report any errors in the comments below as maintainer do not currently own an aarch64 machine. Thanks.