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
