5 ms·

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 ver

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?

tsukikage 8y ago
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.
- hnnh44 8y ago
  Isn't this what semantic versioning tried to address?
- gambiting 8y ago
  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????
rhizome 8y ago
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.

tsukikage 8y ago

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.

hnnh44 8y ago
Isn't this what semantic versioning tried to address?
gambiting 8y ago
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????

rhizome 8y ago

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.