IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This has been clearly lacking while making the previous commit
but the implementation isn't that clear so let it be a separate
step.
The problem requiring the change in subsequent processors
is that these relied upon "@arch" as a flag to be inspected,
and "pkg@!arch1,arch2" on arch2 needs to take out *all* of that
fragment *including* arch1 mention as well.
Part of the cause is difference in handling: "positive" multi-match
would explode its "client" line into multiple lines to filter down
the pipeline, while "negative" multi-match *has* to keep that line
on a similarly single line (otherwise we'd end up with N-1 of those
slipping past the filter for particular architecture thus defeating
the whole purpose of "negative" matching semantics):
$ echo 'pkg@!E2K,mipsel,riscv64' |
sed -r ':loop; s/^((([^@]+@!)[^,]+)+),([a-zA-Z0-9_]+)/\1@!\4/; t loop'
pkg@!E2K@!mipsel@!riscv64
I've tried my best to test this specific change but it still might
introduce a regression in some corner case; feel free to report;
looks like there's a space for improvement in m-p's automated
tests department as well.
So now we can do:
pkg@!ARCHES1,ARCHES2,arch3,arch4
and have pkg excluded on arches mentioned; the previous approach
could only offer explicit whitelists (not that it was entirely
wrong but then again, we have both ExclusiveArch and ExcludeArch
rpmtags in our spec files).
1b5b309bf8