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 <somepackage> >/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
Attachment:
signature.asc
Description: PGP signature