Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Mi, 15 ian 20, 23:11:38, 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. [...] > # 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. Any plans to integrate apt-file (functionality) in 'apt search'? Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser signature.asc Description: PGP signature
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Thu, Jan 16, 2020 at 05:46:56PM +0100, Enrico Zini wrote: > On Thu, Jan 16, 2020 at 01:15:29PM +, Paul Wise wrote: > > > > No, did I give that impression? Sorry, search is going to stay > > > with regex on (I think it's) package names and descriptions. > > > > Speaking of search, are the apt maintainers aware of apt-xapian-index > > and do you have any thoughts on it? > > Speaking as the original author of apt-xapian-index, I orphaned it some > time ago, since nobody's ever built anything, to my knowledge, on top of > its index[1]. aptitude can use apt-xapian-index for searching I think, and I think xapian-style fulltext search makes a lot of sense for the search command, but I have not looked into it closely. > > I assume that the various package management UIs that we have now, are > building their own indices on top of appstream metadata, possibly with > the advantage of it being independent from the underlying packaging > technology. Yes, AppStream has taken over most of the stuff apt-xapian-index was envisioned for I think. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Thu, Jan 16, 2020 at 01:15:29PM +, Paul Wise wrote: > > No, did I give that impression? Sorry, search is going to stay > > with regex on (I think it's) package names and descriptions. > > Speaking of search, are the apt maintainers aware of apt-xapian-index > and do you have any thoughts on it? Speaking as the original author of apt-xapian-index, I orphaned it some time ago, since nobody's ever built anything, to my knowledge, on top of its index[1]. I assume that the various package management UIs that we have now, are building their own indices on top of appstream metadata, possibly with the advantage of it being independent from the underlying packaging technology. Enrico [1] I went as far as prototyping and sharing a market web UI kind of prototype at the time, then I stopped: https://www.enricozini.org/blog/2011/debian/pkgshelf/ -- GPG key: 4096R/634F4BD1E7AD5568 2009-05-08 Enrico Zini signature.asc Description: PGP signature
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Thu, Jan 16, 2020 at 12:57 PM Julian Andres Klode wrote: > No, did I give that impression? Sorry, search is going to stay > with regex on (I think it's) package names and descriptions. Speaking of search, are the apt maintainers aware of apt-xapian-index and do you have any thoughts on it? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Thu, Jan 16, 2020 at 07:01:25AM -0500, Sam Hartman wrote: > Does it really make sense to deprecate regexps for apt-cache search? > In that case, I think you're very unlikely to want a literal match. No, did I give that impression? Sorry, search is going to stay with regex on (I think it's) package names and descriptions. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
Does it really make sense to deprecate regexps for apt-cache search? In that case, I think you're very unlikely to want a literal match.
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Wed, Jan 15, 2020 at 11:11:38PM +0100, 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++. Heh, I totally forgot about the + modifier. So we are still not fully deterministic: apt install/remove x++ means install x+, unless there happens to be an x++. Maybe we can figure out how to solve the modifier problem sensibly, but e.g. moving it to the start didn't work. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Thu, Jan 16, 2020 at 01:49:55AM +, Paul Wise wrote: > On Wed, Jan 15, 2020 at 10:12 PM Julian Andres Klode wrote: > > > # The solution > > I would have thought the way to go would be to introduce explicit > --raw --fnmatch --regex --pattern options for each different package > name matching system. Patterns all start with either ? or ~ and hence are safe - no packages start with that name, and they are easy to filter out too if you want to write a wrapper around apt. So no need for --pattern :D - Patterns subsume regular expressions - The syntax more closely aligns with aptitude - You can combine patterns with literals, which you can't do with options; for example, ~n^linux-image-.*-amd64 foo. Once the shortforms are there, it's also shorter to type than options :) Patterns are coming _precisely_ because I want to avoid having to add ad-hoc options for each and every thing, and unify that into one syntax that works everywhere (policy and search still need work, though). I want you to be able to write ?name(apt) as an argument to install, an argument to show, an argument to search, or as a Package name in the preferences file. One syntax, consistent behavior across all places you can specify package names (except search has a different meaning of literals, because it searches descriptions :D). -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
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 signature.asc Description: OpenPGP digital signature
Re: Deprecating regex/fnmatch fallback for package arguments, and 1.9.6 highlights
On Wed, Jan 15, 2020 at 10:12 PM Julian Andres Klode wrote: > # The solution I would have thought the way to go would be to introduce explicit --raw --fnmatch --regex --pattern options for each different package name matching system. -- bye, pabs https://wiki.debian.org/PaulWise
