On Mon 26 Jun 2017 at 19:01:21 (+0100), Brian wrote: > On Mon 26 Jun 2017 at 13:06:29 -0400, Greg Wooledge wrote: > > > On Tue, Jun 27, 2017 at 03:04:30AM +1000, John Elliot V wrote: > > > Can I ask why you did the apt-get upgrade before the apt-get > > > dist-upgrade? Why not just go straight for apt-get dist-upgrade..? > > > > Probably because (s)he read the release notes: > > > > <https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.en.html#minimal-upgrade> > > The notes are clear but what is the point of following this procedure? > > You do an upgrade, so an upgrade is done. No new packages. Fair enough.
I have a desktop that I don't use very frequently at the moment. Last time I booted it up, the apt-get upgrade downloaded over 70 packages. There was probably a point-release involved. That contrasts with my regularly used machines that apt-get -d upgrade every three hours and email me if their cache contains any packages. If you watch upgrades taking place, you can see that they're phased. Apt-ish and Dpkg-ish are setup before other packages are unpacked, and so on. It's not all just done in one heap. By running upgrade before dist-upgrade, you reduce complexity by maximising the compatibility of packages with each other. When lenny was replaced by squeeze, even these two steps were insufficient; the kernel and udev needed replacing as a pair after the (lenny) upgrade and before the (squeeze) dist-upgrade. > You are none the wiser about what would happen if a dist-upgrade is done > next, so it is still a dive into the unknown. > > Then you dist-upgrade. Why not leave out the previous step, unless there > are packages you wish to keep? Perhaps an illustrative example of when > the single-step process dist-upgrade fails would be helpful. The advice > > This has the effect of upgrading those packages which can be > upgraded without requiring any other packages to be removed > or installed > > simply repeats what apt-get(8) says without its detailed explanation. > > (I upgrade, reboot, dist-upgrade, But I am into cargo-cult). Oh, I forgot. It was necessary, of course, to reboot after replacing the kernel and udev in the lenny/squeeze process, in order for the newly installed kernel to be actually running as opposed to just spinning on the drive. Cheers, David.
