> Many, perhaps most people don't want to think about software. It should just work and you shouldn't have to mess with it. If something is broken, they will ask for help. Somewhat cumbersome procedures are okay as long as they always work and don't change.

There are free software distributions that stick quite close to that model, such as Debian and CentOS. The problem with the Chromebook is that it is only "on support" for 5 years after release, past that it's just a brick. Plus it expects you to depend on outside "cloud" services when there's no real reason to do so - a mainstream Linux distribution won't do that.

> a mainstream Linux distribution won't do that

With apt, there's no straightforward way to download packages on one machine and take them to an offline machine. Apt assumes that you you will be installing on the machine doing the downloading and only downloads the packages the downloading machine needs, which may be different from the one the offline machine needs, and last I checked you had to do quite a lot of piping and text parsing to work around it.

You can add a local file based repository to your sources.list "deb file:/mnt/debian-dvd/ wheezy main contrib", redownloading the whole ISO is probably the easiest way to handle upgrades like this. There's also "dpkg -i <some package file>" will install packages from anywhere.

If those options don't cover your needs can you tell me what they are?

The need is: for any given package, download that package and all dependencies, regardless of their installed status on the current system, so that they can be put on some external storage and taken to the other system.

It's not exactly the same as what you described, but apt-offline[1][2] comes close. You run it on the offline machine to obtain a "signature" which is then used on the online machine to download the correct set of packages.

[1] http://rickysarraf.github.io/apt-offline/ [2] https://www.ostechnix.com/fully-update-upgrade-offline-debia...

So now I have to visit the target, then schlep back to the source, then back to the target again. What if it is several hours away? You know, the kind of place likely to not have an internet connection to do it itself?

To solve the original problem of downloading all potential dependencies without any knowledge about the state of the target machine, I suppose you could just prepare a minimal Debian installation in a container with only essential packages and run "apt-get clean && apt-get -d install $package". In principle you could then copy the downloaded package files to the target and install them offline with dpkg. You'll probably end up downloading much more than you need, though. That's inevitable without two-way communication about the state of the target.

That isn't actually a better solution than the bash and awk hacking that I'm trying to avoid though.

I have no experience with this but there's apt-mirror, basically mirroring the entire repo: https://www.howtoforge.com/local_debian_ubuntu_mirror

We're pretty much at the point where you could mirror the entire archive including every arch onto a portable hard drive, the total size is 2453GB: https://www.debian.org/mirror/size

Great, so best case it takes me 1.13 days to download. Why is this so hard? The whole purpose of a package manager is to know the dependency chain of any given package, yet that information is completely useless because nobody ever considered this simple use case.

This simple use case was actually the norm back when apt was created and most people installed from CD. In fact, if downloading the whole repo is too much you can still order a DVD set: https://www.osdisc.com/products/linux/debian?affiliate=about... .

It is completely ridiculous that I need the entire repository to install a single package and its dependencies. End of story.

You can connect to the public repository or copy your own version of the repository. How else could it possibly work ?

Issue a command to apt that says "download this package and all its dependencies regardless of installed state on this machine".

Five years isn't great, but it's not so bad for something inexpensive, and you need to be able to buy a replacement in case of hardware failure. It's more important that getting a new one is easy, it works the same, and no data is lost.

In my case, it's a nice improvement over maintaining a relative's increasingly unreliable Windows XP computer running obsolete software for long past its expiration date.