Starting with APT 2.0 (1.9.6 in experimental), the apt(8) binary will not try to interpret package names passed on the command-line as regular expressions or fnmatch() style patterns. Future versions of apt-get(8) and apt-cache(8) will follow that change, following the release of bullseye.
# The problem Interpreting arguments as package name, regular expression, or fnmatch expression, depending on which matches first, made apt very unpredictable: The expression `apt install g++` could mean one of - Install the package g++ - If g++ does not exist, install all packages containing g - as + is the one-or-more operator Hence before 1.9.6, `apt install x++` installed any package containing x, whereas `apt install g++` installed g++. This caused problems when a package with a special character such as + or * was removed from the archive, but still used in scripts, as they suddenly would install different packages or fail weirdly. # The solution APT 2.0 introduces patterns, as specified in apt-patterns(5), replicating most of the the pattern mechanism of aptitude, albeit currently with only the long-form syntax being supported. To support existing users, regular expressions that start with ^ or end with $ continue to be supported. This will mainly be important once that change propagates to apt-get and apt-cache. They might cause deprecation warnings in future versions though, but should be around longer than just any regular expression. # Overview of supported arguments The accepted syntax for package names in apt(8) is henceforth: - Patterns: Expressions starting with ?, such as ?name(^apt) - Literal names: Any package name that exists in the cache - Tasks: Expressions ending in ^, such as gnome-desktop^ - Regular expressions starting with ^ or ending with $ All of these can still have /release or =version appended to them. # Outline - 1.9.6 disabled regex and fnmatch matching in apt(8), and mark them as deprecated in the apt-get(8) manual page. - A future version, possibly in 2.0 will add deprecation warnings to apt-get(8) and apt-cache(8) - A far future version, released after bullseye, will completely remove support for regular expressions and fnmatch. # TODO - We should clearly document what is understood in the manual pages. - Should we reenable fnmatch style handling? It's a bit magic, and makes it harder to wrap apt sanely. - Should we hint users at apt-patterns somehow in the error message if there are special characters such as ,*.$^[] and we could not find anything? Makes for better UX, right? - Need to implement the short patterns - ~n^apt , for example, to make things easier to type :) - this might not be ready in time for the upcoming 2.0, but should be around later this year in 2.2. # In other news - Cache generation is about 16% faster for a single-arch amd64 stretch chroot (in memory, on a Core i5-8250U powered T480s) - Hashing is now done by gcrypt, offering about 50% performance improvement on the same platform due to hardware-accelerated implementations of SHA. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en