An option to limit expac to search only specified repos via -S.

[Earnestly]

This is related to issue #23.

I would like to limit expac to search only specific repositories when
specifying -S.

As a work around for this I am instead prefixing the repo name (%r) and using
that as a marker for awk which then prints the remaining column. E.g.

expac -S '%r %n:%E' -l ':' < <(pacman -Sql "$repo") | awk -v repo="^$repo" '$1 ~ repo { print $2 }'

Ideally I would like to constrain -S to the defined $repo above via
something like expac -S --repo=$repo ....

Any thoughts?

[AladW]

Actually you can do this already by specifying the repo name to expac with repo/package pairs. So in case package names are available from several repos, this would work in theory:

pacman -Sl "$1" --print-format='%r/%n' | expac -S '%n %E' -

However, --print-format doesn't work with --list for some reason. pacsift does work:

pacsift --exact --repo="$1" | expac -S '%n %E' -

Note the - after expac so it takes values from stdin, rather than print every sync package. You might also want xargs -r as pacsift returns 0 with no output on a non-existing or empty repo:

pacsift --exact --repo="$1" | xargs -r expac -S '%n %E' -

[Earnestly]

Oh that's nice. pacsift is quite useful here. I've switched to this for the repo-cycle-detector instead, thanks for that.

Perhaps the issue of pacsift not returning zero on non-extant repos should be regarded as a bug? @andrewgregory

[andrewgregory]

I'm not sure what you think having pacsift return non-zero would do here. If you use expac in a pipe it will run regardless of what pacsift returns. What needs to happen is that expac needs to be changed to not fallback to all packages when - is given with empty stdin.

[Earnestly]

Sorry, I didn't mean to talk about return values, I'm being a bit of a derp lately. Yes you're exactly right, if expac ... /dev/stdin or expac ... - is used it shouldn't fallback to all packages if empty.

[AladW]

For the stdin issue, see #29

[falconindy]

So this is basically a dupe of #29? Or is there something else that needs to be addressed?