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

Re: Changing how you do things: Was Re: merged /usr

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

Attachment: signature.asc
Description: PGP signature

Reply to: