Bug#987017: recommends 3 different ways to find obsolete packages, pick one
Antoine Beaupré wrote
>>> aptitude search '~o'
>>
>> This is nice and simple, but frankly as an aptitude user I wouldn't
>> bother. Instead I'd do what the text just above mentions - launch
>> aptitude, notice that there was a category for "Obsolete and Locally
>> Created Packages" (which would tell me I'd somehow lost track of my
>> kernel packages), and purge everything in that category from the
>> full-screen interface, without going back to the commandline.
>
> I think the point here is that you can do:
>
> aptitude purge '~o'
>
> ... to avoid loading the GUI.
I'd imagine it's to avoid having to deal with that interface - it's
much more powerful (and indeed faster) if you're used to it, but we
don't want novice users to need to guess it's "↓↓↓_gg"!
>>> 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.
> 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...
[...]
>>> 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?
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".
>> [---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.
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".
> 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".
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: