aur-pkg-status - a glance at your installed AUR packages

tinhtruong · 2018-09-02 02:26:22

aur-pkg-status - a glance at your installed AUR packages

A small command-line application to check for the AUR package installed on your machine. This is only useful for ArchLinux (and derived distros)

Dependencies

pacman

Make Dependencies

go

AUR package is located at https://aur.archlinux.org/packages/aur-pkg-status/

Feedback is welcome!

Last edited by tinhtruong (2018-09-03 12:06:22)

yan12125 · 2018-09-02 05:31:56

yaourt is full of security issues [1]. You should not suggest it.

[1] https://wiki.archlinux.org/index.php/AU … n_wrappers

tinhtruong · 2018-09-02 08:45:12

Thank yan12125 for your feedback. I will update my post to use yay instead.

Trilby · 2018-09-02 12:40:55

*headdesk* just point users to the AUR package. If you are going to suggest a tool to install it, just suggest the officially supported tool: makepkg?

Please also revise your PKGBUILD to build from source, or alternatively (but not advised) rename it to aur-pkg-status-bin.

Last edited by Trilby (2018-09-02 12:42:11)

graysky · 2018-09-02 12:49:18

Alternatively, there is cower:

% cower -u
:: distccd-alarm-armv6h 8.2.0-2 -> 8.2.0-3
:: distccd-alarm-armv7h 8.2.0-2 -> 8.2.0-3
:: distccd-alarm-armv8 8.2.0-2 -> 8.2.0-3

eschwartz · 2018-09-03 00:21:54

Trilby wrote:

Please also revise your PKGBUILD to build from source, or alternatively (but not advised) rename it to aur-pkg-status-bin.

I'd just like to highlight this advice, and reinforce it with *my* advice that as these are actually the Rules of Submission

ngoonee · 2018-09-03 04:54:53

graysky wrote:

Alternatively, there is cower:

% cower -u
:: distccd-alarm-armv6h 8.2.0-2 -> 8.2.0-3
:: distccd-alarm-armv7h 8.2.0-2 -> 8.2.0-3
:: distccd-alarm-armv8 8.2.0-2 -> 8.2.0-3

cower doesn't indicate if a package has been removed.

tinhtruong · 2018-09-03 12:07:21

Thank you all for your feedback. I've updated the origin post and the PKGBUILD so that the installation will build from the source.

a821 · 2018-09-03 14:17:20

Some issues: a) there are no quotes around $srcdir. b) The license file is missing in the final package.

tinhtruong · 2018-09-05 12:17:03

thanks a821 for the feedback. I've updated the PKDBUILD file.

a821 · 2018-09-05 12:37:27

Is there a reason why you're installing to `/opt`? why not just copy your program to `/usr/bin` and the license to `/usr/share/licenses/aur-pkg-status/LICENSE`?

Last edited by a821 (2018-09-05 12:37:47)

tinhtruong · 2018-09-07 12:06:07

a821 wrote:

Is there a reason why you're installing to `/opt`? why not just copy your program to `/usr/bin` and the license to `/usr/share/licenses/aur-pkg-status/LICENSE`?

I did not know that there's a standard location for license files.
PKGBUILD has been updated.

Stefan Husmann · 2018-09-08 07:56:12

I made a comment on the AUR comment page.

ayekat · 2018-09-08 08:26:57

I would rewrite the GOPATH declaration line in build() as
```
  export GOPATH="$(pwd):$(pwd)/vendor"
```
i.e. ~~use $(...) instead of backticks~~ (EDIT: or just use $PWD instead of invoking pwd; see below), ~~and quote it correctly~~ (see below).
Why is the makedepends array commented out? For building a go program, go is indeed required.
The package() function could be rewritten as
```
package() {
  install -Dm0755 aur-pkg-status-$pkgver/src/github.com/tinhtruong/aur-pkg-status/aur-pkg-status "$pkgdir/usr/bin/aur-pkg-status"
  install -Dm0644 aur-pkg-status-$pkgver/LICENSE "$pkgdir/usr/share/licenses/$pkgname/LICENSE"
}
```
i.e. use the -D option to create all leading paths for the target, ~~and don't use unnecessary ${...} as there is no parameter expansion~~ (see below). I assume that $pkgver needs no quoting here. ~~There is also no real need to use $srcdir here, as package() already starts in $srcdir~~ (see below). ~~And finally, I believe the style guidelines and example PKGBUILDs use 2 spaces for indentation~~ (see below).

Last edited by ayekat (2018-09-09 14:16:42)

tinhtruong · 2018-09-08 12:06:38

@Stefan Husmann and @ayakat: I've updated the PKGBUILD as your suggestions. Thank you.

Trilby · 2018-09-08 13:28:46

ayekat wrote:

... and quote it correctly.

Quotes are harmless there, but they also serve no purpose. It doesn't matter whether there are spaces or other oddities in the current path as it will still be assigned correctly. Quotes would be needed when the value of a variable that may contain spaces is expanded and used in a context where it'd be wrongly tokenized. That is not the case here:

$ cd /tmp
$ mkdir "one dir"
$ cd "one dir"
$ var=$(pwd)
$ echo $var
/tmp/one dir

Works just fine with no quotes on the right side of 'var' assignment. Quotes would be needed if I wanted to do something like `cd "$var"`.

ayekat · 2018-09-08 13:55:00

Ah, true. I had only the `a=foo bar` in mind, where it would fail, but hadn't actually tried the `a=$(echo foo bar)` variant. Thanks for noticing!

eschwartz · 2018-09-09 08:54:00

ayekat wrote:

I would rewrite the GOPATH declaration line in build() as
  export GOPATH="$(pwd):$(pwd)/vendor"
i.e. use $(...) instead of backticks, and quote it correctly.

... or use $PWD which saves a subprocess and a builtin invocation in exchange for accessing a variable that is set by the shell to the same value.

and don't use unnecessary ${...} as there is no parameter expansion. I assume that $pkgver needs no quoting here. There is also no real need to use $srcdir here, as package() already starts in $srcdir. And finally, I believe the style guidelines and example PKGBUILDs use 2 spaces for indentation.

Or, you could stop telling other people what style of bash to prefer, as there is most definitely no "official style" for how many spaces to use for indentation (I religiously use 4), and "unnecessary" ${...} is in fact yet another personal bash programming style choice.

It is, however, correct that we document all functions to start in $srcdir, and therefore it is not required to explicitly cd there. (Some people prefer cd'ing to absolute paths anyway, and depending on the situation you may need to use it in the middle of a function, but I digress.)

ayekat · 2018-09-09 14:08:29

Eschwartz wrote:

there is most definitely no "official style" for how many spaces to use for indentation (I religiously use 4)

Hmm - I have encountered quite some PKGBUILDs that had vim modelines in them that set expandtab and tabstop=2, so I assumed they all originated from the same sample PKGBUILD file. Hence I assumed that this is the preferred PKGBUILD style (because I would otherwise also use 4 spaces and no expandtab for shell scripts).

But now that I took another look at the sample PKGBUILDs provided, this doesn't seem to be true. I must've misremembered that. I apologise.

As for the ${...}, I guess I'm just a bit allergic to it because it (1) is indeed unnecessary, and (2) I occasionally see people mistake it for proper quoting (so they often use ${...} all over the place, and no quoting at all). But it is not wrong per se, so sorry for the noise there.

As for $PWD, I seem to (mis)remember cases where one cannot rely on the variable being set correctly, so I stopped using it in my scripts in favour of calling `pwd`. Will have to check that assumption...

EDIT: After correcting my initial comment, I guess my "feedback" was largely useless. Apologies to the OP - I'll probably leave PKGBUILD reviewing to the more experienced people from now on

Last edited by ayekat (2018-09-09 14:16:14)

eschwartz · 2018-09-09 14:17:31

The sample PKGBUILDs are even worse they use ugly tabs.

As for the unquoted ${...} with spaces in them, I solve this problem by doing both. But sure, it's a problem and people should definitely be reminded where appropriate, that those need to be quoted.

eschwartz · 2018-09-09 14:30:47

ayekat wrote:

As for $PWD, I seem to (mis)remember cases where one cannot rely on the variable being set correctly, so I stopped using it in my scripts in favour of calling `pwd`. Will have to check that assumption...

It depends on which version of $(pwd) you use!

By default, the shell builtin will align with the value of $PWD. You can enforce absolute path resolution using $(pwd -P), and the external binary $(/usr/bin/pwd) will use the absolute path resolution regardless.

Use the builtin rather than the environment variable in the event that you're worried some crazy person will decide to be funny and `export PWD=/this/is/not/my/real/pwd` -- but I think in any other case it should be fine.

Trilby · 2018-09-09 14:54:17

ayekat wrote:

EDIT: After correcting my initial comment, I guess my "feedback" was largely useless. Apologies to the OP - I'll probably leave PKGBUILD reviewing to the more experienced people from now on

Far from it - the feedback provided in this thread provided productive discussions of what is necessary and proper in a PKGBUILD (as opposed to what is stlyistic). Without this discussion people may miss important things or may wrongly assume importance of other things. Whether or not this specific thread is the ideal place for such a discussion is a fair question (to which I'd respond "yes" as separate discussions on rules/style will be mostly ignored or overlooked).

Alad · 2018-09-18 11:01:30

To get back on discussing the actual software... I'd like to see a way to take package names/versions from stdin, rather than have them hardcoded through pacman -Qm. In particular, that would add support for local repos containing AUR packages.

Arch Linux

#1 2018-09-02 02:26:22