Bug#1070258: release-notes: Approach to managing other package managers when upgrading needs documentation
Manny wrote:
> One of the ways I got burnt in the Bullseye → Bookworm full-upgrade is
> documented here:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1070203
>
> There was no signal given before, during, or after the upgrade warning
> that the non-debian python app “argostranslate” would be ruined. It
> was just a surprise the next time the app was needed that it no longer
> functioned.
The Debian package-management system can never guarantee that software
it doesn't know about will continue to work through an upgrade (even
to a new backport kernel, never mind a whole new stable release). If
what happened in this case was that pip3 installed code relying on a
particular version of Python, and then you upgraded the system version
of Python, then there are two approaches to protecting yourself: you
can either stick to Debian packaged Python apps, or set up a whole
separate local Python environment that you take responsibility for.
In theory, non-Debian code ecosystems could help you out here by doing
their own OS-compatibility tests and maintaining their own "release
notes". But that's a lot of work, and unfortunately the developers
who'd need to be doing it have a tendency to ignore OS distributions -
hence all that upstream pip documentation that didn't warn you about
this.
> I’m not sure if the release notes could give any detailed guidance,
> but users should probably be instructed to minimally become aware of
> packages that are at risk. These existing sections are probably
> relevant:
>
> 4.2.6. Remove non-Debian packages
When this says "packages", it means in the APT sense of the word; you
aren't necessarily expected to remove the things that "pip3 list"
would tell you about, just to be aware of them as things that you need
to take care of.
> 4.2.13. Check package status
>
> Perhaps users should probably be instructed to run:
>
> $ pip list
> $ pip3 list
> $ pipx list
>
> to at least become aware of non-Debian packages that might be impacted
> so they can be reminded to give some thought to it. IMO it’s sensible
> to save the lists from that output to a file and then refer to it
> post-upgrade to test these fragile apps so the nasty surprise of lost
> functionality does not manifest at the time that they need to use it,
> which is about the worst time to discover the loss.
>
> Rust also has its own package manager (cargo), as does emacs. I have
> no idea if they have the same special needs that pip does. I don’t
> think cargo gives a listing mechanism so perhaps nothing can be done
> there.
There are myriad different available potential footguns of this
general sort: one or more for every active programming language
ecosystem, plus flatpak, make install, and so on. Once you're using a
local Python environment, there might also be alternatives too new for
the most recent Debian Release Notes to know about.
One workaround that we occasionally try is to have the Release Notes
point at a Debian Wiki page that goes into all the details at length.
In principle that would be possible here, but who would write it? As
far as I can see nobody has ever bothered to put any information about
pip/pip3/pipx on the Debian wiki in all the years they've existed.
--
JBR with qualifications in linguistics, experience as a Debian
sysadmin, and probably no clue about this particular package
Reply to: