APT CLI versioning, interactive/non-interactive split, apt-* deprecation
# CLI versioning
I propose versioning the entire behavior of APT. A complete
specification can be found in [1], but is not entirely up-to-date
on the semantics [the classic-interactive track is no longer
needed, and more breakage is allowed in the tracks].
[1] https://gist.github.com/julian-klode/1926ff9ddcc36fc6d611127c19682388
The basic summary is that we want to allow scripts to use
the apt(8) binary in a safe and predictable way, this includes
both its input, output, and behavior.
APT will support a --cli-version A[.B[.C]] option that allows
specifying the behavior of a specific APT version that should
be emulated. This is a prefix match: The individual major tracks
may receive "breaking" features, but they represent a certain
design philosophy.
## Historical levels
Specifying '0' will replicate the same set of behavior you
currently see with apt-get and friends. The lowest supported
version will be 0.30, indicating the version of the 0 level
at 3.0.0. This level is deprecated and scheduled for removal
no earlier than 2029.
Specifying '2' will replicate the apt(8) UX before 3.0, with
a more classical user interface. This moves forward, so '2.12'
would introduce most behavioral changes introduced in 3.2,
for example.
## Support commitments
Each track 'A' is supported in the following 'A+1' release
series, providing a 10 year life time (+ the life time of
the last release it appeared in, so 15-25 years depending
on distribution).
Each subtrack 'A.B' is supported in parallel to 'A.(B+2)',
so for a 2 year period in the development release. Further
support is provided on a low effort basis.
There is no effort made to guarantee the continuing
availability of specific A.B.C tracks.
Further tracks may be maintained to allow distribution
specific upgrade paths. For example, APT 3.2 is the
default version in Ubuntu 26.04, and APT 3.6 in Ubuntu 28.04
should still support scripts specifying --cli-version 3.2,
so users can migrate scripts to new versions after upgrading.
## Exceptions
The versioning mechanism does not apply to safety-
or security-relevant changes. For example, signing
algorithms are not versioned as part of this mechanism.
# Interactive vs non-interactive
I propose introducing a new --interactive flag, and shipping
profile.d and fish config snippets that essentially do
alias apt="apt --interactive"
alias apt-get="apt-get --interactive"
and so on.
This will allow us to differentiate interactive use from use
in scripts, so we can inform users who run apt-get to use
apt instead, and get rid of the unstable output notice when
piping apt(8) output into another process [since we know you
are running it in an interactive shell].
Further evaluation is needed on what concrete behaviors should
differ between interactive and non-interactive, or mixed mode
(what's the default now).
# Deprecation of apt-*
The apt-* utilities have severe limitations, like
- matching unbound regular expressions:
"apt install g++" matches any package containing g if there
is no package named exactly g++
- they do not prompt about release info changes and fail
instead.
- they do not show dependency types in apt-cache depends.
- they do not support color
- they do not wait for the lock to be acquired and instead
fail directly.
The situation is no longer tenable, it creates safety and
usability issues for users who have not migrated to apt(8);
and we need to move forward, either by moving everyone to
apt, or by moving apt-get and friends to a less stable
target that allows them to receive more bugfixes and features.
## Plan 1: Replacing them wholesale with apt
We suggest replacing them with an
alias apt="apt --cli-version <version you tested with>"
at the start of the script.
9y Provisional timeline (series opening in parentheses):
3.1 (2025-05) - for forky and 26.04
- The apt-* utils will issue a warning if apt-utils is not installed
- The apt-* utils will issue a deprecation warning in interactive mode
3.9 (2029-05) - for forky+2 and 30.04
- The apt-* utilities move to apt-utils
4.1 (2030-05) - for 30.10 and forky+3
- The apt-* utilities will issue a deprecation warning in scripts
4.9 (2034-05) - for 34.10 and forky+cantcount
- The apt-* utilities are removed
4y Faster timeline, as fast as distros permit:
3.1 (2025-05) - for forky and 26.04
- The apt-* utils will issue a warning if apt-utils is not installed
- The apt-* utils will issue a deprecation warning in interactive mode
3.5 (2027-05) - for forky+1 and 28.04
- The apt-* utilities move to apt-utils
- The apt-* utilities will issue a deprecation warning in scripts
3.9 (2029-05) - for forky+2 and 30.04
- The apt-* utilities are removed
## Plan 2: Redirecting them to `--cli-version 2`
We anticipate that removing apt-get will break scripts that detect
a Debian like system by checking for apt-get being present. An
alternative option to this plan is redirecting apt-* utilities from
the '0' version track to the '2' version track:
3.1: Redirect apt-* to behave like `apt --cli-version 2`
3.9: Remove the `--cli-version 0` track
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: