Re: apt 2.0 release notes
* David Bremner: > Julian Andres Klode writes: > >> >> apt install _toremove +toinstall >> > > A common convention is to do something like > > apt install -- -toremove +toinstall > > I would prefer that to rolling our own syntax, unless there's some good > reason (other than the small amount of extra typing) It would also allow to use _ for purging packages.
Re: apt 2.0 release notes
Julian Andres Klode writes: > > apt install _toremove +toinstall > A common convention is to do something like apt install -- -toremove +toinstall I would prefer that to rolling our own syntax, unless there's some good reason (other than the small amount of extra typing) d
Re: apt 2.0 release notes
On Tue, Mar 10, 2020 at 08:36:25AM -0400, The Wanderer wrote: > On 2020-03-10 at 06:58, Julian Andres Klode wrote: > > > On Sat, Mar 07, 2020 at 09:41:44PM +0100, Julian Andres Klode wrote: > > > >> ### Incompatibilities > >> > >> * The apt(8) command no longer accepts regular expressions or wildcards as > >> package arguments, use patterns (see New Features). > > > > Correction - regular expressions starting in ^ or ending in $ (that is, > > anchored) are still being accepted. We know there are multiple scripts > > out there using those, and they are safe to handle. > > > > After evaluating feedback, we'll soon be reinstating wildcards using > > * as well, but no other special characters from glob(7), as most of those > > seem pointless in our context, and limiting our exposure to * makes it > > easier to reason about. > > > > So syntax overview for package arguments: > > > > ^fooRegular expression > > foo$Regular expression > > foo*Wildcard (* may appear anywhere, and multiple times) > > ~fooPattern > > ?fooPattern > > task^ Task > > Just for completeness / clarity, as with when this was announced > previously as upcoming: > > What about inline install/remove markers, of the form > > foo+ > foo- > > , which modify install/remove behavior on a per-package basis in > 'install', 'remove', and (I think) 'upgrade' classes of invocation? > > My understanding from before is that while these still result in > ambiguity depending on what package names exist in the available > repositories, they are not being affected by the current change. Is that > (still) correct? This is correct. > > Are there any known plans for changes regarding this inline > install/remove syntax in the currently foreseeable future? No concrete plans. I do think we need to move to prefix, as a prefix is safe, but - does not work there, so maybe we should do: apt install _toremove +toinstall Suggestions welcome. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Re: apt 2.0 release notes
On 2020-03-10 at 06:58, Julian Andres Klode wrote: > On Sat, Mar 07, 2020 at 09:41:44PM +0100, Julian Andres Klode wrote: > >> ### Incompatibilities >> >> * The apt(8) command no longer accepts regular expressions or wildcards as >> package arguments, use patterns (see New Features). > > Correction - regular expressions starting in ^ or ending in $ (that is, > anchored) are still being accepted. We know there are multiple scripts > out there using those, and they are safe to handle. > > After evaluating feedback, we'll soon be reinstating wildcards using > * as well, but no other special characters from glob(7), as most of those > seem pointless in our context, and limiting our exposure to * makes it > easier to reason about. > > So syntax overview for package arguments: > > ^foo Regular expression > foo$ Regular expression > foo* Wildcard (* may appear anywhere, and multiple times) > ~foo Pattern > ?foo Pattern > task^ Task Just for completeness / clarity, as with when this was announced previously as upcoming: What about inline install/remove markers, of the form foo+ foo- , which modify install/remove behavior on a per-package basis in 'install', 'remove', and (I think) 'upgrade' classes of invocation? My understanding from before is that while these still result in ambiguity depending on what package names exist in the available repositories, they are not being affected by the current change. Is that (still) correct? Are there any known plans for changes regarding this inline install/remove syntax in the currently foreseeable future? -- 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: apt 2.0 release notes
On Sat, Mar 07, 2020 at 09:41:44PM +0100, Julian Andres Klode wrote: > ### Incompatibilities > > * The apt(8) command no longer accepts regular expressions or wildcards as > package arguments, use patterns (see New Features). Correction - regular expressions starting in ^ or ending in $ (that is, anchored) are still being accepted. We know there are multiple scripts out there using those, and they are safe to handle. After evaluating feedback, we'll soon be reinstating wildcards using * as well, but no other special characters from glob(7), as most of those seem pointless in our context, and limiting our exposure to * makes it easier to reason about. So syntax overview for package arguments: ^fooRegular expression foo$Regular expression foo*Wildcard (* may appear anywhere, and multiple times) ~fooPattern ?fooPattern task^ Task Error reporting might still be a bit odd. Also we do not support top-level patterns not starting with = or ~ yet, such as !~napt, because identifying what constitutes a pattern and nicely falling back to other forms is a bit hard. Wrap such patterns in an ?and or ?or, or use ?not instead of ! at the start of a pattern, e.g. Good: ?not(~napt), ?and(!~napt) Bad: !~napt We hope to get this fixed eventually. Thanks everyone. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
Re: apt 2.0 release notes
On 08.03.20 19:10, Jonas Smedegaard wrote: > Quoting Matthias Klose (2020-03-08 18:40:34) >> On 3/7/20 9:41 PM, Julian Andres Klode wrote: >>> # APT 2.0 >>> >>> After brewing in experimental for a while, and getting a first outing in >>> the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. >>> 1.10 would be a boring, weird number, eh? >>> >>> Compared to the 1.8 series, the APT 2.0 series features several new >>> features, >>> as well as improvements in performance, hardening. A lot of code has been >>> removed as well, reducing the size of the library. >> >> $ apt show >/dev/null | cat >> >> WARNING: apt does not have a stable CLI interface. Use with caution in >> scripts. >> >> Is there a roadmap when the CLI interface will become stable? > > I would not expect apt to ever get a stable interface for scripting. > > "man apt" says this in first paragraph of section DESCRIPTION: > >> apt provides a high-level commandline interface for the package >> management system. It is intended as an end user interface and enables >> some options better suited for interactive usage by default compared >> to more specialized APT tools like apt-get(8) and apt-cache(8). > > I.e. for scripting, use apt-get instead. If that last paragraph wants to say "use apt-get for scripting" then it should say it clearly and explicitly and not leave it up to sufficiently astute interpretation skills of the reader... *t
Re: apt 2.0 release notes
On Sun, Mar 08, 2020 at 02:40:56PM -0400, Boyuan Yang wrote: > Hi, > > 在 2020-03-07六的 21:41 +0100，Julian Andres Klode写道： > > # APT 2.0 > > ### Incompatibilities > > > > * The apt(8) command no longer accepts regular expressions or wildcards as > > package arguments, use patterns (see New Features). > > A little comment on this: I am okay with apt(8) no longer accepting regex or > wildcards (which is still unfortunately a feature that I use every day) since > the CLI interface volatility is well announced. I also understand the reason > behind this move. > > However, I saw that there's plan to let apt-* stop accepting them as well > after Bullseye release, according to the NEWS file (v1.9.6 NEWS). Please avoid > this, or at least implement in a backward-compatible way (e.g., letting the > user explicitly specify that they are using regex, apt-patterns or string with > wildcard in the input via cmdline options; the default format is considered to > be the fallback format/behavior). I saw countless scripts using this feature > and the outcome of feature removal would be catastrophic. This will be properly deprecated: * Soft deprecation: Until May 2020 (Ubuntu 20.04) apt-* behaves as before * Deprecation period: May 2020 - April 2022 (bullseye, and Ubuntu 22.04) apt-* will still accept regex/wildcard, but complain with a warning. * Removal: May 2022, post Ubuntu 22.04 release (and well past bullseye hopefully) apt-* will stop accepting wildcard. The deprecation period may be moved forward and shortened by approx one year: * Deprecation period: March 2020 - release of bullseye * Removal: after release of bullseye but only if I find time and get approval to add such warnings to Ubuntu 20.04, given that this is past feature freeze. But I don't think I'm very much interested in that. The removal is absolutely necessary, given the breakage that can happen when a package with a + in the name disappears from the repo. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Re: apt 2.0 release notes
Hi, 在 2020-03-07六的 21:41 +0100，Julian Andres Klode写道： > # APT 2.0 > ### Incompatibilities > > * The apt(8) command no longer accepts regular expressions or wildcards as > package arguments, use patterns (see New Features). A little comment on this: I am okay with apt(8) no longer accepting regex or wildcards (which is still unfortunately a feature that I use every day) since the CLI interface volatility is well announced. I also understand the reason behind this move. However, I saw that there's plan to let apt-* stop accepting them as well after Bullseye release, according to the NEWS file (v1.9.6 NEWS). Please avoid this, or at least implement in a backward-compatible way (e.g., letting the user explicitly specify that they are using regex, apt-patterns or string with wildcard in the input via cmdline options; the default format is considered to be the fallback format/behavior). I saw countless scripts using this feature and the outcome of feature removal would be catastrophic. -- Thanks, Boyuan Yang signature.asc Description: This is a digitally signed message part
Re: apt 2.0 release notes
On Sun, Mar 08, 2020 at 07:10:49PM +0100, Jonas Smedegaard wrote: > Quoting Matthias Klose (2020-03-08 18:40:34) > > On 3/7/20 9:41 PM, Julian Andres Klode wrote: > > > # APT 2.0 > > > > > > After brewing in experimental for a while, and getting a first outing in > > > the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. > > > 1.10 would be a boring, weird number, eh? > > > > > > Compared to the 1.8 series, the APT 2.0 series features several new > > > features, > > > as well as improvements in performance, hardening. A lot of code has been > > > removed as well, reducing the size of the library. > > > > $ apt show >/dev/null | cat > > > > WARNING: apt does not have a stable CLI interface. Use with caution in > > scripts. > > > > Is there a roadmap when the CLI interface will become stable? > > I would not expect apt to ever get a stable interface for scripting. > > "man apt" says this in first paragraph of section DESCRIPTION: > > > apt provides a high-level commandline interface for the package > > management system. It is intended as an end user interface and enables > > some options better suited for interactive usage by default compared > > to more specialized APT tools like apt-get(8) and apt-cache(8). > > I.e. for scripting, use apt-get instead. We need to have an option that allows us to move forward with changes while also giving people the ability to write scripts that keep working. This has two dimensions: - Changes in output. It's reasonably easy to add an extensible output format and an option to switch to that for machine readable output - Changes in behavior. The only thing we can really do here is to version our behavior, and deprecate old behavior, and eventually remove it, while tracking a current and a future version, as debhelper does. It is questionable if we need both, or if we should just have the second one. Arguably, for most commands, you might want to track default behavior but still have a stable output format you can parse, and --machine-readable sounds nicer than --compat 1. I guess we could add a --compat switch now, make it do nothing, and remove the warning. Then when we add new behavior we can mark it for new versions only. Eventually I want to end up at a point where apt-* are symlinks to apt. We did not make it in this cycle (2.0), maybe we'll make it for bullseye (2.2). -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en signature.asc Description: PGP signature
Re: apt 2.0 release notes
On Sun, Mar 08, 2020 at 07:10:49PM +0100, Jonas Smedegaard wrote: > Quoting Matthias Klose (2020-03-08 18:40:34) > > $ apt show >/dev/null | cat > > > > WARNING: apt does not have a stable CLI interface. Use with caution in > > scripts. > > > > Is there a roadmap when the CLI interface will become stable? > > I would not expect apt to ever get a stable interface for scripting. > I.e. for scripting, use apt-get instead. Or in this case, apt-cache. Meow! -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ in the beginning was the boot and root floppies and they were good. ⢿⡄⠘⠷⠚⠋⠀ -- on #linux-sunxi ⠈⠳⣄
Re: apt 2.0 release notes
Quoting Matthias Klose (2020-03-08 18:40:34) > On 3/7/20 9:41 PM, Julian Andres Klode wrote: > > # APT 2.0 > > > > After brewing in experimental for a while, and getting a first outing in > > the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. > > 1.10 would be a boring, weird number, eh? > > > > Compared to the 1.8 series, the APT 2.0 series features several new > > features, > > as well as improvements in performance, hardening. A lot of code has been > > removed as well, reducing the size of the library. > > $ apt show >/dev/null | cat > > WARNING: apt does not have a stable CLI interface. Use with caution in > scripts. > > Is there a roadmap when the CLI interface will become stable? I would not expect apt to ever get a stable interface for scripting. "man apt" says this in first paragraph of section DESCRIPTION: > apt provides a high-level commandline interface for the package > management system. It is intended as an end user interface and enables > some options better suited for interactive usage by default compared > to more specialized APT tools like apt-get(8) and apt-cache(8). I.e. for scripting, use apt-get instead. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: apt 2.0 release notes
On 3/7/20 9:41 PM, Julian Andres Klode wrote: > # APT 2.0 > > After brewing in experimental for a while, and getting a first outing in > the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. > 1.10 would be a boring, weird number, eh? > > Compared to the 1.8 series, the APT 2.0 series features several new features, > as well as improvements in performance, hardening. A lot of code has been > removed as well, reducing the size of the library. $ apt show >/dev/null | cat WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Is there a roadmap when the CLI interface will become stable?
apt 2.0 release notes
# APT 2.0 After brewing in experimental for a while, and getting a first outing in the Ubuntu 19.10 release; both as 1.9, APT 2.0 is now landing in unstable. 1.10 would be a boring, weird number, eh? Compared to the 1.8 series, the APT 2.0 series features several new features, as well as improvements in performance, hardening. A lot of code has been removed as well, reducing the size of the library. Enjoy! ## Highlighted Changes Since 1.8 ### New Features * Commands accepting package names now accept aptitude-style patterns. The syntax of patterns is mostly a subset of aptitude, see `apt-patterns(7)` for more details. * `apt(8)` now waits for the dpkg locks - indefinitely, when connected to a tty, or for 120s otherwise. * When apt cannot acquire the lock, it prints the name and pid of the process that currently holds the lock. * A new `satisfy` command has been added to `apt(8)` and `apt-get(8)` * Pins can now be specified by source package, by prepending `src:` to the name of the package, e.g.: Package: src:apt Pin: version 2.0.0 Pin-Priority: 990 Will pin all binaries of the native architecture produced by the source package `apt` to version 2.0.0. To pin packages across all architectures, append `:any`. ### Performance * APT now uses libgcrypt for hashing instead of embedded reference implementations of MD5, SHA1, and SHA2 hash families. * Distribution of rred and decompression work during update has been improved to take into account the backlog instead of randomly assigning a worker, which should yield higher parallelization. ### Incompatibilities * The apt(8) command no longer accepts regular expressions or wildcards as package arguments, use patterns (see New Features). ### Hardening * Credentials specified in auth.conf now only apply to HTTPS sources, preventing malicious actors from reading credentials after they redirected users from a HTTP source to an http url matching the credentials in auth.conf. Another protocol can be specified, see apt_auth.conf(5) for the syntax. ### Developer changes * A more extensible cache format, allowing us to add new fields without breaking the ABI * All code marked as deprecated in 1.8 has been removed * Implementations of CRC16, MD5, SHA1, SHA2 have been removed * The apt-inst library has been merged into the apt-pkg library. * apt-pkg can now be found by pkg-config * The apt-pkg library now compiles with hidden visibility by default. * Pointers inside the cache are now statically typed. They cannot be compared against integers (except 0 via nullptr) anymore. ### python-apt 2.0 python-apt 2.0 is not yet ready, I'm hoping to add a new cleaner API for cache access before making the jump from 1.9 to 2.0 versioning. ### libept 1.2 I've moved the maintenance of libept to the APT team. We need to investigate how to EOL this properly and provide facilities inside APT itself to replace it. There are no plans to provide new features, only bugfixes / rebuilds for new apt versions. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en
