On 2021-04-15 21:08:27, Justin B Rye wrote:
> 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";.
I should have said "obsolete", I think.
>> 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.
>> 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?
It might help if the former `~o` is expanded to `?obsolete` in the text,
to make it clearer how it compares with the latter.
>> 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.
I actually find the output of apt-forktracer to be quite handy.
>> 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.
Yeah, although I guess that's the point of those commands: figure out if
there's a mess in there.
I find apt-show-versions to be comparable to apt-forktracer, but a bit
more flexible.
>> aptitude search '?narrow(?installed, ?not(?origin(Debian)))'
>
> Yes, that's the one you listed above.
Ah yes, sorry for the dupe.
>> 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 have no idea anymore.
>> 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.
I see. Maybe a quick oneliner explanation before the command could help
alleviate that confusion then...
> 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.
Same here, I guess.
>> 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.
>> 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.
Okay, so just stick to aptitude in both cases then, and don't introduce
apt-forktracer. :)
>> 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.
Yeah, and then we get rid of aptitude in the docs in bullseye +1 :)
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?
Then after the upgrade to bullseye, we use this to find unsupported
/ removed packages:
apt list ~obsolete
And the release notes could use their own TL;DR: before those commands. :)
>> 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.
Definitely. That was mostly meant as a joke.
--
Choose a job you love and you will never have to work a day in your life.
- Confucius
