Bug#987017: recommends 3 different ways to find obsolete packages, pick one
On 2021-04-16 09:19:35, Justin B Rye wrote:
> Antoine Beaupré wrote
[...]
>>>> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
>>>
>>> This one (apparently an improvement on the '~i(!~ODebian)' search that
>>> was recommended for buster, though the logic is too subtle for me to
>>> remember) is looking for a slightly different thing at a different
>>> stage in the upgrade process: it's part of the section about getting
>>> rid of "non-Debian packages" *before* the upgrade. The '~o' and
>>> '!~ODebian' searches find different kinds of "unwanted" package.
>>
>> Maybe it would be worth clarifying that distinction then?
>
> I don't know how we make texts more separate than printing them
> in two different places with explanatory paragraphs that talk
> about different things! But let me have a look.
>
> # 4.2.2. Remove non-Debian packages
> #
> # Below there are two methods for finding installed packages that did
> # not come from Debian, using either aptitude or apt-forktracer.
> # 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. Wait, why *is* 4.2.2 before 4.2.3? shouldn't it be
> * sort out the package database (pending actions or whatever)
> * make sure you're at the latest point release
> * remove any non-Debian packages
> * similarly but separately, remove any obsolete packages
> * tidy any relic configs
> [...]
> Maybe this is turning into the sort of disruptive low-priority change
> that should wait for next time.
Indeed. It does seem like 4.2.3 should be before 4.2.2.
I am not sure we should tell people to "remove any non-Debian package"
before the upgrade. They might have legitimate reasons to have
third-party package repositories...?
>> It might help if the former `~o` is expanded to `?obsolete` in the text,
>> to make it clearer how it compares with the latter.
>
> Unfortunately people also use "obsolete" to mean "autoremovable"!
> And this also makes the search less simple and easier to confuse with
> the one in 4.2...
I just meant to avoid using the shortcut, obscuring it won't help with
this sort of confusiong.
> [...]
>>>> In my personal documentation, I've settled on `apt-forktracer`,
>>>
>>> I'd be interested to know what you find it useful for.
>>
>> I like that it shows the related versions in the archive, and that it
>> has very terse output.
>
> 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 have forgotten, it's been years since you messed around with your
sources.list.
> 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".
I am not sure we want the release notes to standardize on that as
well... But I have considered writing a parser that checks sources.list
Origin headers and fixes things up correctly. Because my checklist is
getting ridiculous:
: Check for pinned, on hold, packages, and possibly disable &&
rm -f /etc/apt/preferences /etc/apt/preferences.d/* &&
rm -f /etc/apt/sources.list.d/backports.debian.org.list &&
rm -f /etc/apt/sources.list.d/backports.list &&
rm -f /etc/apt/sources.list.d/bullseye.list &&
rm -f /etc/apt/sources.list.d/buster-backports.list &&
rm -f /etc/apt/sources.list.d/experimental.list &&
rm -f /etc/apt/sources.list.d/incoming.list &&
rm -f /etc/apt/sources.list.d/proposed-updates.list &&
rm -f /etc/apt/sources.list.d/sid.list &&
rm -f /etc/apt/sources.list.d/testing.list &&
apt update && apt -y upgrade &&
>>> [---suture---]
>>>> I actually forgot that bullseye itself introduces yet another one:
>>>>
>>>> apt list ~obsolete
>>>
>>> And indeed for section 4.8, which is dealing with tidying up *after*
>>> the upgrade, it might make sense to recommend the use of apt instead
>>> of aptitude here.
>>
>> Yeah, and then we get rid of aptitude in the docs in bullseye +1 :)
>
> Aptitude may no longer be recommended for dist-upgrades, but there are
> still reasons to prefer it for day-to-day admin on stable systems.
I'm not arguing for deprecating aptitude altogether, but it would seem
to me that using less tools in the release notes would be better.
> For bullseye-to-bookworm we'll probably want to use apt recipes
> wherever possible, with at most a mention that aptitude can also do
> this from the fullscreen mode. But since we also point at 4.8 from
> 4.2, we can't do that yet; we don't want the extra complication of
> having to say "if you haven't upgraded yet then use aptitude".
Agreed.
>> So, TL;DR: we should have this before, to find and cleanup foreign
>> packages:
>>
>> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
>>
>> Presumably `apt list` might support that as well in bullseye?
>
> Afraid not - "E: Regex compilation error".
That's really too bad! ;)
a.
--
To be naive and easily deceived is impermissible, today more than
ever, when the prevailing untruths may lead to a catastrophe because
they blind people to real dangers and real possibilities.
- Erich Fromm
Reply to: