Re: Bug#987017: recommends 3 different ways to find obsolete packages, pick one
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
Reply to: