[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#987017: recommends 3 different ways to find obsolete packages, pick one



Antoine Beaupre wrote:
> The release notes, in sections 4.2.2 and 4.8, actually suggest *three*
> *different* ways of finding what are essential orphaned packages:

I don't think you mean "orphan" in either of the senses known to
"https://wiki.debian.org/Glossary#orphan";.
 
>     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.

>     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.

>     apt-forktracer | sort

I've never quite been able to understand how it is that anybody
could get themselves into the situation of *needing* this specialised
package installed to work around the weirdness of their setup, but
still need to be told what it is that's unusual about their system.
 
> Then I also know of those:
> 
>     apt-show-versions | grep -v /bullseye

This is another package I've never needed to install on my stable
desktop precisely because it's my stable desktop.  If I had a reason
to install it, presumably I'd already know about the reason, and step
one in the bullseye upgrade process should be to get rid of that.

>     aptitude search '?narrow(?installed, ?not(?origin(Debian)))'

Yes, that's the one you listed above.

>     aptitude search '?narrow(?not(?archive("^[^n][^o][^w].*$")),?version(CURRENT))'

Does that do something similar to the above, but less intelligibly, or
something different?
 
> I frankly don't quite know where I stand with all this anymore, but I
> am getting the strong feeling we're sending an incoherent message
> here. :)

It's two different messages in two different parts of the release
notes.  The first message is roughly "before the upgrade, look at what
you've got installed.  If it's a mix of complex pins and PPA packages
and nonsense like that, start by getting rid of all the crazy stuff".
Unfortunately, this relies on the reader to apply some common sense,
so we've fallen into the trap of replacing "subjective" advice with
"objective" diagnostic commandlines.

The second message is "after the upgrade, throw out all the stuff
that isn't supported any longer".  This really is trivially easy to
automate, as long as you don't confuse it with the previous task.
 
> In my personal documentation, I've settled on `apt-forktracer`,

I'd be interested to know what you find it useful for.

> but I
> suspect we might want to stick with `aptitude search '~obsolete'`
> because that matches other documentation in the release notes (and
> allows for easy purging).

But it isn't looking for the same thing.
 
> Is there any reason why we have all that diversity?
> 
> What's the right way to do what we actually want here?

 [---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.

> Apparently, those are also a thing:
>
>      comm -23 <(dpkg-query -W -f '${db:Status-Abbrev}\t${Package}\n' | grep '^.[^nc]' | cut -f2 | sort) <(apt-cache dumpavail | sed -rn 's/^Package: (.*)/\1/p' | sort -u)
>      apt list --installed | awk -F/ '/\[installed,local\]/{print $1}'

If they're not getting shorter, you're going the wrong way.
-- 
JBR	with qualifications in linguistics, experience as a Debian
	sysadmin, and probably no clue about this particular package


Reply to: