For that to work you'd have to have your own repository with all the packages you install. Old specific versions will not be preserved in the upstream repos if a new package is released.
Right, but that's not really a problem, is it? My understanding is that committing dependencies is strongly discouraged -- if you're writing libraries or modules intended for distribution and others' use. On the other hand if you're deploying a standalone app, locking down any specific dependencies' versions and committing them is actually considered a best practice, as it's the only way to be sure it won't unexpectedly change. Right? I'm genuinely interested in others' thoughts and experiences here.
The problem is that you're now forcing all of your users to use the library you bundled. First, this bloats the system, since you now don't share dependencies between applications. Second, it makes the system more complicated because there are multiple library copies floating around the filesystem. Third, it means that when you really do need to change a library/dependency, you can't just update the libfoo package, you have to update every application.
In my experience (Linux on the desktop), bundling dependencies is an indicator of poor software quality, but I realize that the situation may be different on other systems.
In this case, I think that the solution is to use the distro's package manager to pin minor versions and rely on the distribution's updates for security fixes. Hosting your own repo is a bad idea, since it means you won't get any software updates. Software updates are really important -- they have security patches and bug fixes. If you're worried about the distro changing something from under your feet, you should pick something more stable. Debian or CentOS are good choices.
Ok, but here it seems like you're referring to "[my] users" as if they were consumers of the library -- that is, as if they were developers. That's still my first case in which I agree committing / bundling dependencies is a bad idea. I'm talking about the 2nd case, of locking down dependencies used to build an application whose "users" are not even aware of the presence of dependent libraries nor the structure nor configuration of the underlying software. In this second case, isn't [freezing/shrinkwrapping/committing/bundling] the dependencies generally considered the right thing to do?
Of course, updating the dependencies (whether for patches or more consequential updates) in subsequent releases is fine... but within a given release cycle, one otherwise runs the risk of unexpected inconsistency, between e.g. a developer build and a CI build done a short time later.
That is just basic common sense. It is easy to mirror upstream repos that you need. Don't allow your systems to have dependencies that are outside of your control.
