Well, you'd be wrong then. If you went into a car dealership and asked for a new rearview mirror, and they gave you (and charged you for) a new car, you'd be rightly surprised.
Or better yet, if you ask apt get to update a package, you damn sure don't expect it to update itself.
Nothing else works like this, and shouldn't. It's just not what most people need or expect, or even want.
I'm pretty sure homebrew does this, and it's awful behaviour.
Every time you think I'll just.. and then you have to sit and wait whilst it does it's thing..
It can be disabled, and it was changed from every time to once every 24 hours years ago, but still..
`go build` is a very high-level command. I'd compare it to going to a car dealership and asking them to 'make the car usable'. You think only a small part is broken but the dealership determines that it's incompatible with the current law and you need to get a new one.
If you want to build go project in a hermetically sealed environment (where it doesn't fetch anything unknown or unexpected from the internet), use for example Nix. When building software with Nix, the sandbox doesn't have access to the internet and all project dependencies must be specified via the Nix language.
So several things in the world at present work like this; whatever one might say about their being expected, needed, or wanted.
If a package requires a newer version of apt and said version is available then I would absolutely expect apt to do so. apt is after all just another package.
This might be true for apt, because that’s how it always worked, but is this true of modern package managers? Like if I do `brew install X` I expect the latest version of X, which might require updating brew. I definitely don’t want the latest version of X my local brew install happens to know about. As an example, doesn’t pretty much every Dockerfile installing dependencies from apt call apt-get update -y?