36 zu 0 bei 5 Enthaltungen. So ging im September 2025 die Abstimmung aus, PECL nicht mehr zu empfehlen und alle auf PIE zu verweisen, den PHP Installer for Extensions. Dreizehn Monate später würde ich wetten, dass in den meisten deiner Dockerfiles noch eine Zeile mit pecl install steht, und ich verstehe auch, warum. Ich finde trotzdem, du solltest diese Zeilen noch in diesem Quartal rauswerfen. Weil der RFC bewusst kein Abschaltdatum festlegt, bestimmst du das Timing selbst, und wer früh umsteigt, entscheidet mit, wie das Ökosystem aussieht, wenn der Rest von uns nachzieht.

Das Gegenargument ist stark, also will ich es ernst nehmen. Der RFC hat nur die Kommunikation geändert. PECL funktioniert weiter, nichts soll abgeschaltet werden, und um die Website oder das Tool zu entfernen, bräuchte es einen eigenen RFC, den bisher niemand geschrieben hat. Dazu kommt, dass noch nicht jedes PECL-Paket umgezogen ist: PIE findet nur Extensions, die auf Packagist mit "type": "php-ext" in ihrer composer.json veröffentlicht sind. Wenn eine deiner Extensions noch nicht portiert wurde, hängst du für diesen Build an PECL fest. Abwarten kostet heute nichts. Wer vernünftig ist und einen vollen Backlog hat, sagt „später“ und macht mit seinem Sprint weiter.

Genau hier komme ich zu einem anderen Schluss. Das fehlende Paket ist der eigentliche Grund, jetzt zu migrieren, denn genau das willst du herausfinden. Stell ein CI-Image auf PIE um, schau, welche Installation scheitert, und du hast eine präzise Liste der Extensions, deren Maintainer einen Schubs oder einen Pull Request brauchen. Für Extension-Autoren ist der Fix im Wesentlichen ein Manifest: ein Name, der Typ php-ext (oder php-ext-zend), eine Lizenz, eine PHP-Constraint und optional ein php-ext-Block mit Schlüsseln wie extension-name und configure-options. Das ist ein Nachmittag Arbeit für irgendwen, und ein freundliches Issue von jemandem, der es tatsächlich ausprobiert hat, ist mehr wert als ein weiteres Jahr Funkstille. Wenn du nicht auf den Maintainer warten kannst, hilft dir pie repository:add vcs in der Zwischenzeit weiter.

Auch im Alltag spricht einiges für den Wechsel. Die Namen folgen dem Composer-Schema, aus xdebug wird also xdebug/xdebug, und gesucht wird auf packagist.org/extensions. Das fühlt sich vertraut an für alle, die öfter composer require getippt als zu Mittag gegessen haben. Am besten gefällt mir, dass PIE die INI für dich schreibt. In dem Walkthrough, den ich gelesen habe, gebaut mit PIE 1.5.2 auf PHP 8.3, legte es eine conf.d-Datei mit priority=80 und einer extension=-Zeile an und meldete das Modul danach als aktiviert und geladen. Ich habe mehr als einen nächtlichen Incident erlebt, der am Ende auf eine .so hinauslief, die einwandfrei kompiliert, aber nie eingeschaltet wurde. Diese ganze Fehlerklasse wird gerade deutlich kleiner.

Für Container bindet das Muster aus der offiziellen Doku das Binary aus dem Image ghcr.io/php/pie:bin per Bind-Mount nur für einen einzigen RUN-Schritt ein, sodass PIE nie in deinem finalen Image landet. Flags wie --auto-install-build-tools und --auto-install-system-dependencies beantworten die Rückfragen, an denen ein nicht interaktiver Build sonst hängen bleiben würde. Auf einer Maschine mit mehreren PHP-Versionen kannst du mit --with-php-config gezielt php-config8.2 ansteuern, während PIE selbst auf allem ab 8.1 läuft, und es zeigt dir bei jedem Befehl ganz oben die Zielinstallation an. Das ist besser als das alte Ritual, zu raten, welches phpize gerade als Erstes im PATH liegt.

Es ist nicht alles poliert, und ich erzähle dir lieber selbst von den Ecken und Kanten, als dass du sie im Diff deines Config-Managements entdeckst. Beim Deinstallieren entfernt PIE die .so, lässt die INI-Datei aber liegen, mit auskommentierter Zeile und einem kleinen Hinweis „removed by PIE“. Ich halte das für eine vertretbare Entscheidung, denn eine Datei zu löschen, die du vielleicht von Hand angepasst hast, wäre schlimmer. Wer Ansible oder Puppet nutzt, wird aber Drift sehen und braucht eine Aufräumregel. Außerdem brauchst du Root-Rechte, weil das Modul direkt im System-Extension-Verzeichnis landet, und die Doku sagt zu Berechtigungen nicht viel. Mitgelieferte Extensions wie gd oder mysqli deckt PIE ebenfalls nicht ab, docker-php-ext-install behält also seinen Job. Nichts davon hält dich vom Ausliefern ab.

Im Kern geht es mir also darum, wer sich zuerst bewegt. Eine Deprecation ohne Frist wird nur dann zu Ende gebracht, wenn die Nutzer den Druck aufbauen, den sonst ein Datum erzeugt hätte, und das Ökosystem kommt auf Packagist an, ein gescheiterter CI-Lauf und ein freundliches Issue nach dem anderen. Die Go-Leute würden jetzt anmerken, dass sie für so etwas nie einen Compiler-Schritt gebraucht haben. Geschenkt, wir haben phpize, und das läuft jetzt wenigstens von selbst.

Deshalb meine Frage an dich: Welche eine Extension in deinem Stack hält bei dir noch eine pecl install-Zeile am Leben, und hast du ihrem Maintainer schon Bescheid gesagt? Ich würde die Liste gern in den Kommentaren sehen, denn ich vermute, sie ist kürzer, als wir alle denken.