On Wed, Aug 18, 2021 at 08:33:01AM +0100, Tim Woodall wrote: > […] and time taken updating this > script to apt "because the documentation says I should" is time I cannot > spend on more interesting stuff (from my PoV)
For the record: The apt documentation says the opposite. /usr/bin/apt is even annoyingly insistent on not being run inside a script or even its output being redirected to a file. I was talking (in half-jest) about interactive usage – aka your fingers typing all commands manually into a terminal one by one. That is also what the release notes are primarily concerned with. We know perfectly well that apt-get is used all over the place in the strangest of usecases by scripts potentially nobody knows howto or has the time to maintain. As a result apt-get (and the rest of the apt-* family) aren't changing their behaviour much if at all from release to release, which results in some behaviour being suboptimal if not downright bad, but the default none the less as it would be too costly to change the default (a fun example of a minor change having unexpected consequences is breaking Debian CD building with apt-cache show #712435). apt on the other hand can be changed "at will" as we expect a being on the other side of the terminal who is able to react to changes like a new question asking if this potentially security relevant change is okay & expected. Scripts can't usually react, with them we can only communicate via failing the execution if we deem the risk high enough to do so to hopefully summon a being capable of reasoning to look into the failing of the script. btw: `apt-config dump Binary::apt` will tell you (most) of the config options apt changes compared to the 'old' defaults in apt-get and co. There aren't that many (so far). Best regards David Kalnischkies
signature.asc
Description: PGP signature
