apt/test/integration/test-apt-patterns, branch 2.1.19Debians commandline package managerhttps://git.kalnischkies.de/apt/atom?h=2.1.192020-05-04T11:08:33Zapt list: Fix behavior of regex vs fnmatch vs wildcards2020-05-04T11:08:33ZJulian Andres Klodejulian.klode@canonical.com2020-05-04T11:08:33Zurn:sha1:c4f85bcb8bee1b5e647c7e629f616cffc7d12bbc
Previously (and still in cacheset), patterns where only allowed to
start with ? or ~, which ignores the fact that a pattern might just
as well start with a negation, such a !~nfoo.
Also, we ignored the --regex flag if it looked like this, which
was somewhat bad.
Let's change this all:
* If --regex is given, arguments are always interpreted as regex
* If it is a valid package wildcard (name or * characters), then
it will be interpreted as a wildcard - this set of characters is
free from meaningful overlap with patterns.
* Otherwise, the argument is interpreted as a pattern.
For a future version, we need to adapt parsing for cacheset and
list to use a common parser, to avoid differences in their
interpretation. Likely, this code will go into the pattern parser,
such that it generates a pattern given a valid fnmatch argument
for example.
Reinstate * wildcards2020-05-04T10:48:56ZJulian Andres Klodejulian.klode@canonical.com2020-05-04T10:23:50Zurn:sha1:75f59b16312523ab3deb995c48e8c8ae07586c23
Reinstate * wildcards as they are safe to use, but do not allow any
other special characters such as ? or [].
Notably, ? would overlap with patterns, and [] might overlap with
future pattern extensions (alternative bracketing style), it's also
hard to explain.
Closes: #953531
LP: #1872200
Don't crash pattern matching sections if pkg has no section2020-03-10T09:57:21ZDavid Kalnischkiesdavid@kalnischkies.de2020-03-10T09:46:56Zurn:sha1:429effb963fba7529b8ff57d6b0474916d4fed69
Packages from third-party sources do not always follow the established
patterns of more properly maintained archives. In that case it was a
driver package for a scanner&printer device which has only a minimum of
info attached, but also minimal non-installed packages do not include
sections, so we really shouldn't assume their availability.
apt(8): Disable regular expressions and fnmatch2020-01-15T21:19:17ZJulian Andres Klodejulian.klode@canonical.com2020-01-15T21:01:54Zurn:sha1:21cb4a9e513ccb6f376fbcaf67957c4851cbbe32
This is the first step. Next step will be to add warnings to
apt-get and then remove support there as well.
patterns: Add ?section2019-11-26T11:01:42ZJulian Andres Klodejulian.klode@canonical.com2019-11-26T11:01:42Zurn:sha1:a93b4443c18ee211691f7b336b161fea7d1df699patterns: Add ?all-versions2019-11-26T10:56:28ZJulian Andres Klodejulian.klode@canonical.com2019-11-26T10:56:28Zurn:sha1:96f795bce665a1907b885bd2d57d6ab22b0a4199patterns: Implement ?narrow(...), as ?any-version(?and(...))2019-11-26T10:46:06ZJulian Andres Klodejulian.klode@canonical.com2019-11-26T10:45:44Zurn:sha1:94b185bb738e063bcc387e31b39dcd041f283766
This is pure syntactic sugar - ?narrow does not exist in the
abstract syntax.
patterns: Add ?any-version2019-11-26T10:34:34ZJulian Andres Klodejulian.klode@canonical.com2019-11-26T10:34:34Zurn:sha1:6801e6d2c63d4ff087024fc84a0feb8aef86886bpatterns: Add ?origin2019-11-25T10:32:19ZJulian Andres Klodejulian.klode@canonical.com2019-08-21T20:53:25Zurn:sha1:02b0afd5098534eff34a8fa1d44454c7a3e1ff09patterns: Add ?archive2019-11-25T10:32:19ZJulian Andres Klodejulian.klode@canonical.com2019-08-21T20:31:01Zurn:sha1:391c9f20208584bf429c7717047a0637d0d670fb