Bug#987017: release-notes: Giving many ways to do something *is* useful
Hi, [Release Team member hat on] On 27-04-2024 11:48 p.m., Manny wrote: As an aptitude user, I was bothered by the lack of aptitude ways of doing things in the upgrade guide. I anything, I prefer the Release Notes to move to using one tool in the instructions, without insinuating that it's the only way. I think that tool should be apt nowadays. We've made steps in that direction during the last release cycle, i.e. we moved away from aptitude. 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. I don't think it's the role of the Release Notes to do this. We should show a consistent document and use examples that work. Which also means we should ensure they remain working. Doing that work for multiple tools is extra work I don't want to spend. 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, I understood that that used to be the case in the past. apt is now much more apt. 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. Both call libapt-pkg6.0(|t64), both are higher level tools using the same library, just like packagekit and synaptic and more. 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. Ok, so we should give more reason, see below and patches welcome. 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? non-debian package can create situations where apt (the library) can't resolve the situation anymore or has more difficulty. And then yes, it should be clear you're on your own to solve the situation. I *think* that apt can opt for removal of packages in some situations. Normally for a pure Debian system, you would expect that to happen for things you still need (and a bug would be fair), while if it happens because on non-Debian packages, it's unfair to call that a Debian bug. 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. Ack. 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. Agreed. Or might cause other packages to be removed, so extra care and attention during the upgrade is needed. 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. That's not the purpose of the Release Notes. 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. We could add a statement that while more tools exist. All automated testing of upgrades that I know of use apt-get, so that's the obvious choice. aptitude doesn't get as much testing. Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#987017: release-notes: Giving many ways to do something *is* useful
Package: release-notes Followup-For: Bug #987017 X-Debbugs-Cc: debbug.release-no...@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
