On 2019-07-10 at 15:03, Neil McGovern wrote: > On Wed, Jul 10, 2019 at 07:51:18PM +0100, Julian Gilbey wrote: >> But I realised later that this is going to bite all users when they >> come to upgrade from buster. Perhaps some aptitude and apt-get >> patches can go into a stable (buster) point release, so that fewer >> users are hurt by this in 2-3 years' time? It is quite a >> showstopper! > > Given the release notes tell people to use "apt update", I'd be > interested to know if there was any documentation you read or > followed during the upgrade. If you didn't use the release notes, is > there a reason why? Could a tl;dr version make you more likely to > read them? For myself, no, a shorter/simplified version of the release notes probably wouldn't have made me more likely to read them. I track testing by that name (and have done so for well over a decade), and dist-upgrade on at least a weekly basis, so I never actually upgrade to a new release; I just start pulling from the new testing when the old one moves out from under my feet to become stable. Since I'm not upgrading to a new release, but just sticking with testing as I've been doing all along, I wouldn't think to check release notes. That's especially true just after the release of a new stable; at that point, it's intuitively obvious that testing can't have release notes, because until new package versions migrate from unstable the new testing is *empty*. (Whether this intuition is accurate or not.) As Julian apparently did, I only found the solution for this by a Google search for the error message I was seeing - in my case, in what I recall as being a months-old bug report, since it it hadn't been brought up post-release on e.g. debian-user yet by then. The release notes might be a valid place to document this for people upgrading from oldstable-buster to stable-bullseye after the release of bullseye, or even (if this would be applicable) switching from stable to testing-bullseye midway through the release cycle; it's considerably more reasonable to expect people to think to check release notes before upgrading at those stages. But for people who are merely sticking with testing, after the buster release just as after previous releases, the release notes are IMO not an appropriate answer. Also: I would have tried to reject a "just use 'apt update'" solution, as you say the release notes propose, and kept searching for a way to do it using apt-get - since that's my preferred client, and the idea of switching clients just for a single task like this strikes me as intuitively wrong somehow. In fact, it's possible that I *did* do that; I remember skipping multiple search results which suggested only that solution, and it's even possible that the release notes were one of them. I'd have given in eventually if no "native" solution were to be found, but since in this case one *does* exist, IMO it's not appropriate to present only the solution which would require me to temporarily switch clients. David Kalnischkies presented three different solutions, suitable for different clients, earlier in this thread. IMO, if the release notes need to document any of them, they should document all - or, if it's considered more reasonable to restrict the release notes to discussing one single recommended client, there should be another document somewhere which lists not only all of these solutions but (for discoverability's sake) as many of the client-specific error messages as may be practical. (For those clients which don't present the solution themselves, of course.) -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature