Debian Trixie | Upgrade script support thread

[MichaIng]

Similar to how we did for Debian Bullseye => Bookworm upgrades, we created a script to upgrade from Debian Bookworm to Trixie: https://github.com/MichaIng/DietPi/blob/dev/.meta/dietpi-trixie-upgrade

To upgrade your Debian 12 Bookworm based system to Debian 13 Trixie:

sudo bash -c "$(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/dev/.meta/dietpi-trixie-upgrade')"

From DietPi side, all base features and software options have been tested, though many via automated install tests, checking that the install procedure goes through, expected services are running, network ports are up, CLI commands succeed. The test matrix can be seen here: https://github.com/MichaIng/DietPi/wiki/Debian-Trixie-testing

If your system has a software title installed which is not supported on Debian Trixie (yet), the script will warn you about that, giving you the option to abort.

More info about Debian 13 Trixie can be found on our blog: https://dietpi.com/blog/?p=4014

[hrfried]

I gave this a shot and worked mostly fine, except for a conflict with sabnzbd and python3-jaraco* packages. Always a hassle working with python out of venvs. ;)

Also a note that it might be good to mention bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/refs/heads/dev/.meta/dietpi-trixie-upgrade') has to be run as root, and can't be run directly with sudo, except with something like sudo bash <(curl -sSf 'https://raw.githubusercontent.com/MichaIng/DietPi/refs/heads/dev/.meta/dietpi-trixie-upgrade').

I usually don't like curl pipe to bash as a general rule...much less sudo pipe to bash, but for trustworthy projects I guess it's alright. Just a comment. More details on conflict below.

Just a note that this was done on an Rpi Zero 2 W, and not one that I was actually using for anything "real" yet. I had installed some random packages to play around a bit and test the trixie update, but that's about it. Bookworm build was thrown on here ~1 week ago.

Crux of the issue is that debian python3-setuptools now pulls in python3-jaraco.text:

dietpi@DietPiZero1:~$ apt depends python3-setuptools
python3-setuptools
  Depends: python3-pkg-resources (= 78.1.1-0.1)
 |Depends: python3-importlib-metadata
  Depends: <python3-supported-min> (>= 3.10)
    python3
  Depends: python3-jaraco.text
  Depends: python3-more-itertools
  Depends: python3-typeguard
  Depends: python3-typing-extensions
  Depends: python3-zipp
  Depends: <python3:any>
    python3
  Breaks: python3-wheel (<< 0.46.0)
  Suggests: python-setuptools-doc

(
Same from bookworm, for reference:

dietpi@DietPi4:/etc/apt$ apt depends python3-setuptools
python3-setuptools
  Depends: python3-pkg-resources (= 66.1.1-1+deb12u1)
  Depends: python3-distutils
  Depends: <python3:any>
    python3
  Suggests: python-setuptools-doc

)

which then pulls in python3-jaraco.functools

dietpi@DietPiZero1:~$ apt depends python3-jaraco.text
python3-jaraco.text
  Depends: python3-autocommand
 |Depends: python3-importlib-resources
  Depends: <python3-supported-min> (>= 3.9)
    python3
  Depends: python3-jaraco.context
  Depends: python3-jaraco.functools
  Depends: python3-more-itertools
  Depends: <python3:any>
    python3
  Depends: python3-inflect

which then conflicts with the pip install process:

...
  Attempting uninstall: jaraco.functools
    Found existing installation: jaraco.functools 4.1.0
error: uninstall-no-record-file

× Cannot uninstall jaraco.functools 4.1.0
╰─> The package's contents are unknown: no RECORD file was found for jaraco.functools.

hint: The package was installed by debian. You should check if it can uninstall the package.

[FAILED] DietPi-Software | pip3 install -Ur requirements.txt
...

Removing the offending python packages allowed the process to complete after retrying.

Don't think I'd have time in the near future, but this really shouuuuld be put into a venv. I don't let coworkers fuck around with system python outside of containers anymore for exactly this reason. :)

Just a note, I have more detailed logs/apt deptrees upon request. Not sure if they'd be useful or not. It's late and I need to go to bed, so excuse any bad formatting/wording.

[MichaIng]

Thanks for testing.

Right, <(command) as well as < <(command) and similar do not work with sudo, since the implied temporary file is lost before bash can use it. A command | sudo bash pipe breaks TUI dialogues. Only variant would be sudo bash -c "$(command)", not sure why we did not suggest that one in our Bookworm release blog post (I just took the command from there). I adjusted it and added sudo, should work fine like that.

Regarding SABnzbd:

• A venv seems resonable indeed, given the large number of specific dependencies and versions: https://github.com/sabnzbd/sabnzbd/blob/develop/requirements.txt#L13
  Though I wonder why it tries to uninstall the dist module instead of just overriding it with the site module. But that again, in theory, could break another dist module or package which depends on the exact/not older jaraco.functools the Debian package ships.
• But in fact, this is the very first report with a clear dist vs pip module conflict I ever faced, while we pretty consequently avoid venv for all software installs and override the externally-managed flag present since Debian Bookworm.
• A question here is why python3-setuptools is actually installed. We install pip via get-pip.py and recent setuptools, and there was only a single case where the Debian package was needed temporary due to a bug in another Debian package. Since PyPI provides pre-compiled modules in nearly all cases, and the Python ecosystem develops fast, IMO the Debian packaged Python modules are mostly irrelevant.
• But with the "externally managed" things more commonly used, even that I am a fan of efficient resource sharing, I guess we will need to move more and more Python software installs into venv. That this becomes more common across distros, as well as pipx etc, is indirectly leading to stricter Python dependencies and more conflicts remaining unnoticed or ignored.

[squassina]

Tried to update a pihole + unbound installation, but after the reboot the services were not started automatically.

I'm looking so I can restore, and I'll post the updates here.

Update: unbound service was not automatically started, so I had to do systemctl enable --now unbound.

Ok, DNS (unbound + pihole) is still not coming up. Need to investigate a little more.

Update2: pihole-FTL also needed to be started manually. Now it's working.

Is this something expected for these services? Are other services that should be handled manually?

[hrfried]

I'll have to respond better when I have more time, but yeah it's really a nightmare understanding what python is going to try to do, and distributions have been (rightfully so) moving more and more toward disabling the ability to even mess with python out of a venv. I've had weird issues like python sourcing random forgotten dependencies in ~/.local left behind from old install scripts at work, and e.g. inadvertently grabbing an ancient copy of libssl with it, but leaving no indication that it was actually pulling in that dependency without serious lsof digging (pyside2 has always been a nightmare in itself honestly)...

I've been incredibly happy with uv lately and it's brought my insane workflow of python/pip/pipx/pyenv/pyenv/poetry crap all into one single tool. Basically create a pyproject.toml (easy to convert from a requirements.txt), uv sync to bootstrap a venv with the dependencies, then just source it and you're good to go. Upgrading major python version? uv python list to find available versions, uv python pin cpython-<version> (it'll drop a .python-version similar to pyenv), and then uv sync and you're good to go again. Want to upgrade a single dependency? Change a number/comparator in the pyproject.toml. Also creates lockfiles of dependencies by hash upon syncing.

It's insanely fast compared to anything else I've ever used too...It does do a lot of caching, which might need to be handled specially for dietpi since there's the SD card constraint for many users, although I've used UV a bit on my rpis and haven't seen any issues.

I always sound like a zealot when I talk about it, but its really been a gamechanger.

I think there may have been some other issues with a couple services failing after install, but I'll have to come back to this when I have more time.

[lukaszsobala]

Hello,

I tried the script today and it stopped when encountering a package that was not in the repositories (syncplay-common I think). I then did apt -f install (which did not remove this), apt autoremove (probably a bad idea!), then apt remove syncplay*, then reran the script. It seems to have finished successfully, reboot went OK.