Add hook targets

[bartoszek]

Hook checks only dependencies of updated packages.

[maximbaz]

Thank you, this is very interesting 👍

Why do you think we need to limit the depth of recursion? I expect we will filter out 99% of the stuff anyway when making the repository filter

[bartoszek]

By default packages should list all they link time dependencies, as stated in Arch packaging guidelines. Checking reverse dependencies one level deep shold be enough then.

On the other hand, due to sheer level of packages reliance, doing infinite recursion leads to a lots of unnecessary checks e.g. my laptop with ~1.3k packages has this number of infinite vs. intimidate reverse dependencies.

infinite imidiate pkgname
 537     18     xz
 555     12     krb5
 556      4     keyutils
 557      6     libldap
 559      3     libsasl
 560      4     e2fsprogs
 578     23     expat
 615     43     openssl
 637     12     libffi
 675     21     bzip2
 678     15     libutil-linux
 695     44     perl
 702      6     db
 702      8     gdbm
 795     70     zlib
 937      2     bashrc-manjaro
 937     80     bash
 953     21     readline
 972     39     ncurses
1029     82     gcc-libs
1282    227     glibc
1283      2     linux-api-headers
1283      2     tzdata
1283      4     filesystem
1284      2     iana-etc

[maximbaz]

Thanks, yes this makes a lot of sense. But in this case let's remove the argument and hardcode depth of recursion to 1. Just like from time to time I catch AUR packages that don't declare git as makedepends, this semi-artificial restriction would actually help catching AUR packages that don't declare all of their dependencies. What do you think?

[bartoszek]

Done.

[maximbaz]

What I meant is removing -d argument completely and hardcoding pactree -rud1, would you be okay with that?

[bartoszek]

Well I don't really like this solution, but it's your call :smirk:

[maximbaz]

Could you elaborate? That's why I am asking for feedback 😄 When would you not use -d1?

[bartoszek]

Nothing particular :suspect:, just filling better to have this type of options exposed. From the users point of view there's no difference.

[maximbaz]

Could you please review my commit in your branch? It would be simpler for me to understand and maintain this syntax, but I want to make sure it doesn't have some unexpected side-effects that you wanted to avoid. For example, I saw you added eval but I didn't understand the purpose for it? Or why do two sorts instead of one sort -u after if-fi.

[bartoszek]

LGTM.

[maximbaz]

Thank you for your contribution!