Rebuild WordPress on LAMP instead of carrying its own web stack #5

New issue

Open

opened 2026-09-27 20:45:48 -03:00 by marcos-mendez · 0 comments

marcos-mendez commented

2026-09-27 20:45:48 -03:00

(Migrated from github.com)

The published WordPress layer is a child of mariadb with units none, and
it installs Apache and PHP itself. That was deliberate and is recorded as
such: the maintainer wanted a working appliance to test, and the short path
was one layer over a database that already existed rather than waiting for the
component extraction and the shared web layer.

Both have landed. apache-php is a layer with a green boot test, and LAMP is
its child carrying the mariadb unit, in two variants.

Closes when WordPress is a child of lamp, carrying no web stack of its own,
with the manifest recording the units it inherits so nothing re-runs a conf
script it should not. Expect the layer to shrink: today it duplicates roughly
what apache-php holds.

Two things to decide while doing it, and to write down rather than assume.
Whether WordPress should also have a variant on lamp-client, for an operator
whose database is elsewhere, which is the case decision 0013 calls phase 1 and
the one that motivated the whole database topology plan. And what happens to
the published wordpress layer in the meantime: its parent mariadb c1d6fe68
is current, so it keeps resolving, and it should not be withdrawn before its
replacement is published.

The maintainer's demonstration container runs from an assembled rootfs rather
than from the mirror, so publishing a replacement does not disturb it.

The published WordPress layer is a child of `mariadb` with `units none`, and it installs Apache and PHP itself. That was deliberate and is recorded as such: the maintainer wanted a working appliance to test, and the short path was one layer over a database that already existed rather than waiting for the component extraction and the shared web layer. Both have landed. `apache-php` is a layer with a green boot test, and LAMP is its child carrying the mariadb unit, in two variants. Closes when WordPress is a child of `lamp`, carrying no web stack of its own, with the manifest recording the units it inherits so nothing re-runs a conf script it should not. Expect the layer to shrink: today it duplicates roughly what `apache-php` holds. Two things to decide while doing it, and to write down rather than assume. Whether WordPress should also have a variant on `lamp-client`, for an operator whose database is elsewhere, which is the case decision 0013 calls phase 1 and the one that motivated the whole database topology plan. And what happens to the published `wordpress` layer in the meantime: its parent `mariadb c1d6fe68` is current, so it keeps resolving, and it should not be withdrawn before its replacement is published. The maintainer's demonstration container runs from an assembled rootfs rather than from the mirror, so publishing a replacement does not disturb it.