Bug#987017: release-notes: Giving many ways to do something *is* useful
Package: release-notes
Followup-For: Bug #987017
X-Debbugs-Cc: debbug.release-notes@sideload.33mail.com
@ Antoine Beaupre
> Is there any reason why we have all that diversity?
> …
> 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.
As an aptitude user, I was bothered by the lack of aptitude ways of
doing things in the upgrade guide. I had to research and use guesswork
to work out what is the aptitude-equivalent command, which complicated
my effort. For the minimal system upgrade, users were directed to run
“apt upgrade --without-new-pkgs”. I thought why is the aptitude
approach missing? Is aptitude incapable of this? I then went to the
man page and found “aptitude safe-upgrade”. I am still not sure if
that is the equivalent command. And if so, is it exacly the same or
are there differences?
Whether someone wants to know a bit of many tools or be a master of
few tools is a matter of preference, but the docs would ideally
accommodate both kinds of users (though not necessarily in the same
doc… that’s another matter - but if the different methods are
side-by-side in the same doc it helps users learn about the
equivalences and makes it easier for them to settle on a preferred
method). But certainly it’s sensible to drop methods that have no
advantage of any kind.
The advice I was given early in my Debian years was that apt-get was a
more primitive command and aptitude was more complete/comprehensive,
that it logs or tracks more things and generally the better tool
according to folks giving IRC support. I think aptitude calls apt
IIRC, which makes it a higher level tool.
> 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...?
Concur. I’m not sure what the past release notes said, but the
Bookworm release notes simply bluntly direct users to “Remove
non-Debian packages”. This was frustrating for me. **Why?** I want to
know why I am doing something. The list of non-Debian packages
contained pkgs *I need*. Users need to know why they are directed to
destroy something they need.
Is there a real likeliness that a non-Debian pkg will make a mess or
disaster of the upgrade? Or is this step a generic “we only
officially support our officially distributed software” scenario?
I decided to go against the guidance. There was one non-Debian pkg
that I no longer used, so removal was a trivial choice for that
one. But I left the other non-Debian pkgs alone. Some of them broke
and some survived.
The guide should probably suggest removing any non-Debian pkgs that
are not needed to mitigate dependency complications, but simply warn
that non-Debian pkgs allowed to persist might not run correctly and
should be also treated with low priority if conflicts arise.
@ Justin B Rye
>> 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"
If the guide is intended to help train the user and advance their
Debian skills, then the CLI advice is probably favorable because it’s
more likely to improve the user’s knowledge than a UI that needs no
manual.
If the guide is intended to just execute steps to do a job (git’r
done), then the CLI is still the winner because it’s just one line for
a user to copy-paste and get instant results with minimal text and
minimal reading.
Briefly mentioning the UI option probably doesn’t hurt though in
addition to the CLI.
>> 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.
> …
>> In my personal documentation, I've settled on `apt-forktracer`,
>
> I'd be interested to know what you find it useful for.
For me, apt-forktracer gives 1 pkg additional output:
$ apt-forktracer | sort
linux-image-5.10.0-16-amd64 (5.10.127-2)
linux-image-5.10.0-19-amd64 (5.10.149-2)
linux-image-5.10.0-6-amd64 (5.10.28-1)
linux-image-5.10.0-7-amd64 (5.10.40-1)
linux-image-5.10.0-8-amd64 (5.10.46-5)
mastodon-archive (1.4.4-izzy1)
openjdk-11-jre (11.0.23+9-1~deb11u1) [Debian: 11.0.22+7-1~deb11u1]
openjdk-11-jre-headless (11.0.23+9-1~deb11u1) [Debian: 11.0.22+7-1~deb11u1]
ungoogled-chromium (90.0.4430.212-1.sid1)
ungoogled-chromium-common (90.0.4430.212-1.sid1)
ungoogled-chromium-sandbox (90.0.4430.212-1.sid1)
ungoogled-chromium-shell (90.0.4430.212-1.sid1)
wire-desktop (3.35.3348-3348)
xdiskusage (1.60-4~bpo12+1) [Debian Backports: 1.60-4~bpo12+1] [Debian: 1.48-10.1+b1]
The “apt list '?narrow(?installed, ?not(?origin(Debian)))'” command
excludes the last line (xdiskusage). If those two commands are
expected to have identical results, then maybe we have a bug.
>> 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.
Yes, assuming the intent of the guide is purely to get a job
done. OTOH, the long versions are a good learning opportunity.
If this were a PDF-formatted textbook, it would be tempting to put the
lengthy but academically rich versions in a distinctly colored
sideline box maybe with a graduation hat or some nerdy symbol in the
corner to make it easy for people in git’r done mode to ignore and
simultaneously easy for curious minds to study.
> 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".
Can you elaborate? Why would aptitude lose ground on dist upgrades?
Is it deficient in some way?
As an aptitude user, my temptation is to look for the aptitude
approach. So merely omitting aptitude from the guide only encumbers
aptitude users. If there is a good reason for omitting an aptitude
approach, the guide should state why. Otherwise users might question
the quality and comprehensiveness of the guide.
Reply to: