DietPi default image moved to Bookworm
Closed this issue · 15 comments
als Info für dich. Wir haben das DietPi default Image inzwischen auf Bookworm aktualisiert. Eventuell solltest du deine User informieren, dass über unsere offizielle Download Seite dietpi.com Bookworm images angeboten werden. Bullseye ist nur noch über den direkten Link https://dietpi.com/downloads/images/ verfügbar. 😉
Danke für den Hinweis - das haben wir auch schon mitbekommen ;-) Wir haben zum Download des Bullseye Image einen Hinweis in unser Wiki aufgenommen.
Wir werden auch auf Bookworm umstellen, sobald ihr es als stabil kennzeichnet. Aktuell steht bei Euch noch der Hinweis: "...as not all software in our catalogue is compatible with Debian Bookworm yet" auf der Downloadseite. Deswegen haben wir noch nicht umgestellt.
Grundsätzlich sind die Bookworm Images als Stable anzusehen. Es gibt aktuell noch Probleme mit dem RPi Repository, da sie keine Bookworm Pakete bereitstellen, was aktuell Schwierigkeiten bei der Installation von FFMPEG verursacht. Da ist es an der RPI Fondation dieses hoffentlich bald nachzuholen. Bei den anderen Softwaretiteln gibt es die meisten Probleme mit ARMv6 SBC, da hier einfach die Unterstützung für einige Softwaretitel in Bookworm fehlt. Eine Übersicht haben wir in unserem Wiki erstellt https://github.com/MichaIng/DietPi/wiki/Debian-Bookworm-testing
Ich ping einfach mal unseren Entwickler @MichaIng an.
Oh, Deutsch auf GitHub, wie ungewohnt 😄.
Soweit ich weiß nutzt LoxBerry ja nicht das dietpi-software Skript, sondern eigene Plugins für die Software-Installationen, und DietPi nur als Basissystem/Kernel/Bootloader Unterbau, richtig? In dem Fall ist her Hinweis auf unserer Downloadseite nicht relevant. Dieser bezieht sich auf die vorkompilierten Binaries welche wir teils von den Softwareherstellern selbst (deren GitHub Releases oder Webseiten) herunterladen. Wenn diese gegen Bibliotheksversionen kompiliert wurden welche nur mit denen von Debian Bullseye kompatibel, oder nur dort überhaupt verfügbar sind (wie OpenSSL/LibSSL 1.1), dann laufen sie auf Bookworm nicht. Dasselbe gilt für APT Repositories von den Entwickeln selbst, welche oft noch keine Bookworm Suite haben, und somit in manchen Fällen Paketabhängigkeiten auf Bookworm nicht aufgelöst werden können.
Sofern man die Binaries selber auf Bookworm kompiliert (bzw gegen Bibliotheken welche auf Bookworm verfügbar/kompatibel sind), gibt es kein Problem, für alles andere: Probieren geht über Studieren.
Debian Bookworm selbst muss man seit dem Release letzten Monat als stabil ansehen, was alle APT Pakete mit einschließt.
Wie @Joulinar sagte: Die fehlende Bookworm Suite auf dem Raspberry Pi APT Repository (welches den Kernel, Bootloader und einige Hardware-optimierte Media-Softwarepekete liefert) verursacht gerade Probleme. Die Suite ist schon da, aber enthält noch keine Pakete: https://archive.raspberrypi.org/debian/dists/bookworm/main/binary-armhf/Packages
Ich bin gerade am basteln einer Lösung, aber es ist nicht ganz trivial. Sobald diese fertig ist und entsprechend neue RPi Bookworm Images bereit stehen, sage ich noch mal Bescheid.
Danke für euer Feedback. In der Tat nutzen wir DietPi eher als "Unterbau" für unsere WebUI. Allerdings können unsere Plugins auch Software im System nachinstallieren - und teilweise nutzen wir dazu auch eure Pakete aus dietpi-software.
Wir haben den Hinweis auf die Bullseye-Images in unserem Wiki ergänzt und warten einfach, bis ihr soweit seid. Wobei ich mich schon etwas gewundert habe, dass ihr ein Image zum Default macht, welches noch nicht "fertig" ist :-)
Das ganze liegt nicht an unserem Image. Eher an den Software Herstellern die nicht Bookworm ready sind oder wie die RPI Foundation die einfach länger braucht um Bookworm Pakete bereitzustellen, obwohl Debian Bookworm schon vor 1 Monat offiziell released wurde. Wie @MichaIng schon sagt, von unserer Seite ist es stable.
dass ihr ein Image zum Default macht, welches noch nicht "fertig" ist :-)
Die images sind "fertig". Das Problem mit der RPi Repo Bookworm Suite wurde durch ein ungewöhnliches Paketupdate der RPi Foundation verursacht, nachdem wir unsere Downloads bereits umgestellt hatten. Mittlerweile haben wir es gelöst 🙂. Abgesehen davon ist es völlig normal, dass nicht alle Softwaretitel auf allen Distributionsversionen installiert werden können. Das gilt auch anders herum: Manches lässt sich auf Bullseye nicht mehr installieren, oder wir installieren eine ältere Softwareversion weil die neusten nicht mehr mit Bullseye (e.g. zu altes PHP oder Python) kompatibel sind, aus Sicherheitsgesichtspunkten problematischer.
What are the blockers actually? Only big one I can imagine is LMS (Logitech Music Sever).
But if that plugin could fetch the sever from here, where the nightlies are built, this should be no problem normally: https://downloads.slimdevices.com/nightly/?ver=8.4
We could actually implement this for nightly LMS version for Bookworm and above, until it gets released. Better than nothing, I guess. However, indeed from my POV Bookworm is in the meantime equally or better supported than Bullseye, so this should not be a blocker.
The problem is not LMS - the plugin already fetches the nightly builds. So no issue here.
Currently LoxBerry installs fine on Bookworm. But there are very big issues that let as hesitate to move officially from Bullseye to Bookworm. These issues have nothing to do with DietPi nor LoxBerry, but with Bookworm and their big changes they made to Python and PHP.
LoxBerry "lives" from the plugins one can install on it. And there are around 30 or 50 authors of plugins, some (a lot of) of them are not very experienced in programming and do not spent much time for their plugins. So the most important goal for Loxberry was in the past, that as many as possible plugins are compatible with the new versions of Loxberry without any changes.
And here's the problem:
-
Debian 12 (Bookworm) changes the Python3 installation dramatically. It is not possible to install additional pythonpackages with pip anymore. One now has to use a virtual env where you have to install your additional packages (e. g. with pipx). This will break almost all plugins which based on Python! This is a "no go" at the moment!
-
Debian 12 (Bookworm) removed support for Python2. We still have some plugins which are based on Python2. But since Python2 is deprecated for many years now, I can live with that.
-
Bookworm comes with PHP 8.2, which introduces some more or less important changes to PHP 7.x. A lot of scripts shipped with Loxberry for years now had to be adjusted. This is no big deal for us, but maybe a bigger issue for the plugin developers as well.
So for now Loxberry will stay with bullseye. But again: This decission has nothing to do with DietPi itself. LoxBerry installs on DietPi very well and runs stable without issues. Problem at the moment are the incompatibilities with Python and PHP.
Thanks for the elaborate response!
Just brainstorming, no real experience with it:
- Can we use pipx instead? And symlink pip/pip3 to pipx to provide backward compatibility?
Or use the (not recommended flag) --break-system-packages for legacy/unupdated plugins?
https://www.debian.org/releases/bookworm/amd64/release-notes/ch-information.en.html#python3-pep-668
- Are there so many breaking changes? Is there an easy way to check plugins for PHP 8 compatibility?
Could we use some polyfills maybe to provide some kind of backward compatibility?
Anyway, I want to give loxberry on boomworm a go. Is it as simple as adjusting the install script, or do you have more (local) changes to try this out?
Many thanks! 🙏
- Instead of using the command flag, it is also possible to bypass the issue via config file (generally it is possible to pass any flag/option via config file):
echo -e '[global]\nbreak-system-packages=true' > /etc/pip.confThe problem is caused by the libpython3.11-stdlib package, which ships the file /usr/lib/python3.11/EXTERNALLY-MANAGED to prevent Python module from being installed outside of a venv. I also find this causing more problems than it solves. I never heard of someone who really broke a Python module previously installed via APT with the same module installed via pip (or any dependency), but I know a lot of cases like this one, where preventing this is causing issues.
It would be also possible to remove the flag file, but of course it returns on any APT upgrade, so then you'd need to exclude it via dpkg.cfg.d as well.
-
Indeed, it is probably time to intentionally drop support for project which were not able to migrate to Python 3 within the dozens of years it exists 😉. We did so with Bullseye 2 years ago already, even that there was still a dedicated
python2package with a limited set of modules for backwards compatibility. -
Especially a huge amount of deprecations of old syntax and lossy coding style is now throwing a lot of warnings. Those are usually trivial to fix, but going through by times large code bases simply costs much time.
- Instead of using the command flag, it is also possible to bypass the issue via config file (generally it is possible to pass any flag/option via config file):
echo -e '[global]\nbreak-system-packages=true' > /etc/pip.conf
This is maybe a way to go for a limited period of time. I will check that out - thanks!
Thanks @MichaIng - this seems to work for us. We included this trick into our installation to be compatible with older plugins and it seems to work. Using pipx seems not to be too complicated - but we have to prepare our plugings for the changes.
So LoxBerry is now also officially on Diet Pi Bookworm :-)
Great news, I hope PHP plugin devs won't have too many issues with this 🙂.
Should be fine know. With Release 3.0.0.7 LoxBerry is "ready" for bookworm.