Hacker News Reader

Comment by bigbugbag | Hacker News Reader

Except it doesn't work that way as some package name have changed and the command fails due to some package not existing anymore.

It give something to start with but still requires human intervention from someone who knows how to navigate in this mess.

View on HN

I actually remember running into this issue a lot when building Docker images. Generally you want your docker image to be reproducible so you'd want to lock versions of your dependencies. But when doing this with apt-get install, a lot of the time I find that when a new version of a package is released, the old one gets removed and becomes no longer accessible, so locking versions actually ends up resulting in _more_ build flakiness than just using the latest of whatever package available at build-time, which is obviously not ideal.

Deleting older versions of packages that people may still be relying on seems like a very obvious no-go in a dependency management system. Any idea why this happens regardless? Is it just a matter of costs? Or is there more nuance to it that I'm missing?

The entire software industry has shifted to a stance of not caring when updates break user workflow, experience, functionality and habits. For basically any modern piece of software, whether/when to take each update, rather than being a no-brainer, is a very difficult decision: it is impossible for the end user to separate security/functionality fixes from workflow/functionality-breaking behaviour changes. Everything, across the board, universally, suffers from this: web browsers (few plugins survive browser updates), office software (ui rearranged every time), operating systems (packages and entire applications just vanish)...

Visible behaviour and functionality is changed or removed without user involvement, choice or recourse, turning every update into a game of Russian Roulette. Even LTS builds don't mean no breakage of behaviours users rely on.

From the developer's POV maintaining security/bugfix-only forks of every feature branch rapidly becomes intractable as a project gains complexity / matures. Meanwhile, for startups, "move fast and break things" is the creed. So as we demand more from our software overall, this situation can only get worse, not better.

The temptation for modern users to say "you know what? it's MY bloody computer, not yours; my problems are actually more important to me than whatever you think you're solving" and unplug from the update streams is overwhelming.

Isn't this what semantic versioning tried to address?

Yep. I think I'll literally stop taking Android upgrades because of this. Just few years ago I'd get really excited every time new version of firmware was released for my phone, but now I loathe it - every single damn time the interface changes and you can't do anything about it. Like now I have taken the upgrade to Android Pie for my OnePlus 5T, and....the clock moved to the left now. Ok, google for a solution - nope, can't move it back to the right. Someone somewhere decided that this is "better" so the customer has to accept it. Like you said, I'm getting really fed up with this - is it my phone, or not????

But when doing this with apt-get install, a lot of the time I find that when a new version of a package is released, the old one gets removed and becomes no longer accessible, so locking versions actually ends up resulting in _more_ build flakiness than just using the latest of whatever package available at build-time, which is obviously not ideal.

I would maintain a local apt repository for that situation.

It gets worse when dependencies have changed and now you've installed a library that's incompatible with the dependencies of an app you need and everything grinds to a halt.

Yeah, I've found that enough things change between installs that it's really tough to automate the process. Instead I keep a document that lists all the steps I need to set up my dev machine from scratch (with a data backup), and each time I go through the process I update the document. That makes it much less taxing than trying to figure out and remember everything without a guide, but is flexible enough to handle the inevitable differences from one time to the next.

If you're provisioning machines on a regular basis it's a different story, but if it's your own personal machine that you're reinstalling maybe every couple years this seems like the most straightforward approach.

Also: Use LVM and snapshot before updating to save yourself a lot of headaches.

I went one step farther and built an Ansible role for my workstation and try to install everything via that role. I don’t always, but it sure makes reloads and new machines easier to deal with. I have since split it into a couple roles for full desktop vs somewhere I just ssh into but have enough access to install things to suit me.

When package names change, or don't exist any more, it requires human intervention even when the rest of the update process is automatic. This is the difference between `apt-get upgrade` and `apt-get dist-upgrade`. All you're really doing by putting off the update in that case is compressing all the little bits of human intervention you'd have been doing during every update, into one big push.

Reply on news.ycombinator.com