On 2020-01-15 at 17:11, Julian Andres Klode wrote: > 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. Currently, there is another syntax related to the use of + at the end of package names on the apt command line. At the moment, these two commands both do the same thing: apt-get remove package1 package2+ apt-get install package1- package2 Specifically, both commands will install package2 and remove package1. This syntax is convenient and intuitive for nearly all cases, but like the behavior you describe, means that the result of a given command technically depends on what packages are available in the current known archive. For example, if someone ever uploaded a package named 'g+' into some archive, I don't actually know what 'apt-get remove g++' would wind up doing on a system with that archive configured as available. Will this change have any effect on the ability to use that syntax? If so, what will the resulting behavior be like, and what syntax will we be able to use to achieve similar "mix and match install and remove in the same command line" results (preferably with similar levels of convenience)? -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature