[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 <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

Reply to: