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
