Hendrik Boom wrote: > On Fri, Apr 16, 2021 at 09:19:35AM +0100, Justin B Rye wrote: >> # Please note that neither of them are 100% accurate (e.g. the >> # aptitude example will list packages that were once provided by >> # Debian but no longer are, such as old kernel packages). >> >> Now that you come to mention it I've always thought that was a bad >> example, since after all it isn't exactly a false-positive - old >> linux-images really are no-longer-Debian packages, and if you've got >> some lying around even before the upgrade, this would be an >> appropriate time to get rid of them, as we go on to say a little >> later. > > Old kernels are sometimes kept around as a kind of backstop in > case a new kernel turns out not to work properly.
Sure, that can be how you come to have old ones unpurged; but you can't safely treat a kernel from what's now oldstable as "known good", because when you reboot into it you might quite easily discover that it's incompatible with the stable udev/libc/whatever. >> Yes, but how do you come to be running a system with non-Debian >> repositories in your sources and installing packages to inspect the >> gory details without already realising you've done that? > > You may have forgotten. > > You may have long ago enabled a nonDebian repository to install some > nonDebian package. Unbeknownst to you, that repository also contained > variants of debian packages which ended up replacing the Debian packages > you expected to keep. > > A real mess. They look like Debian packages, but they are not. > > Th the extent that the new packages have more recent version numbers than > the intruding packages, things may still go well. It's a pity "apt policy" is no easier to interpret than the old apt-cache equivalent. But this does begin to make a bit more sense when I consider the issue of pinning - you can't check your system is sane *just* by a glance at /etc/apt/sources.list. Plus, tools like this can make obvious sense on a testing/unstable development system, so you might have got used to it there and then installed it on your stable desktop as well. >> Now that we've got "https://deb.debian.org/debian/", we're close to >> being able to say that standard procedure is "for the duration of the >> upgrade, comment out any lines that don't match that URL". > > Sounds like a valid thing to do, anyway. We might (next time round) say something to the effect that "the recommended setup is to have a basic sources.list as similar to fig 1 as possible. Although many variations are possible and will work reliably on a stable system, you should consider simplifying things for the upgrade". -- JBR with qualifications in linguistics, experience as a Debian sysadmin, and probably no clue about this particular package