Adminer abandoned, install AdminerEvo instead (in v19.x - based on Debian 13/Trixie)

[JedMeister]

The upstream developer of Adminer appears to have abandoned it. Development continues by a new team in a renamed fork: AdminerEvo. The Debian Adminer packager is working on a new AdminerEvo package (see Debian bug #1055329 which hopefully should be ready by the time Debian 13/Trixie is released as stable.

Hopefully we should be able to just change the name (and probably the paths for our custom bits) and it should "just work".

This issue unfortunately (likely) also raises another issue that we have in dependency fulfillment in fab - IIRC fab is not able to handle virtual packages, so may well try to install php-mysql regardless!? That needs confirmation and can be an issue for another day...

[a3s7p]

The fab issue would be moot if using containers.

Unlike the original Adminer, AdminerEvo does not ship an official container image so far.

However,

1. There is the unofficial https://hub.docker.com/r/shyim/adminerevo
2. We could probably trivially mount it to something like the php-fpm container.

[JedMeister]

The fab issue would be moot if using containers.

Perhaps under many/most circumstance, but IIRC there was an issue with a python virtual package required in core. OTOH it's low priority because that only time we've hit it we worked around it by updating the plan to explicitly install a package that provided the required virtual package.

Unlike the original Adminer, AdminerEvo does not ship an official container image so far.

While using containers for the primary upstream software is a no brainer, IMO there are pros and cons to using containers vs Debian packages when available. I'm particularly hesitant to use an "unofficial" container by an "unknown" maintainer. No shade on the dev of the AdminerEvo container, I'm sure they're fine, but I'm not really happy using a container that isn't either an official one (or maintained by a "known" trustworthy dev) or one we're maintaining ourselves.

---

The other thing we still need to work out is if/how we do LXC builds for appliances that rely on app containers to provide their functionality?!

AFAIK with the appropriate guest config (on the host) it's not particularly hard to run app containers in LXC, but it doesn't "just work" OOTB and we have no control over that config on the host. The Proxmox devs have made clear that they have no intention of supporting docker guests directly. For hosting docker guests on Proxmox, they recommend only running them within a "proper" VM - i.e. KVM.

I have no issue not supporting LXC for certain apps - e.g. Canvas and other upstream apps where the only official/supported releases are containers (which we aren't already shipping anyway). But making life more difficult and/or making our apps less reliable for Proxmox LXC users is something to avoid. FWIW I recall getting a ton of complaints and support requests in the early days of systemd where some services wouldn't run under default LXC config and I'd rather not create a similar situation.

I'm also not keen on having to build and maintain 2 different build processes just to provide all of our current build targets.

TL;DR I'm not saying that we can't use containers, but we need to work out how we do the LXC builds before we use containers for everything everywhere.

[a3s7p]

@JedMeister thanks for your input, I was just mentioning available options, not really suggesting a course of action yet 🙂

Official container or DIY would be best indeed.

Using the Debian package and running it containerized are not mutually exclusive, this is actually what I meant by "mounting it to php-fpm". I haven't checked but running it in a container should be as easy as having it installed on the host and mounting the files to a container which can run PHP where php-fpm is the most obvious option. Then the nginx reverse proxy just uses that as a backend.

Re LXC: if running Podman (which has different/fewer requirements than Docker) containers inside LXC is not practical, then we could either run in a VM or "convert" the container-based appliance to LXC images.

Running containers inside a Linux VM to launch containers there is what Docker on Mac does, ie. it's a configuration supported by upstream. IIRC Podman also has something like that so perhaps something we could piggyback on top of for Proxmox builds.

You're right that 2 build processes are not ideal. The way I see it is that we should use containers if that makes things easier for us (like with Canvas and maybe here) and if that's not compatible with a build target, we can apply per-target patches with buildtasks or similarly.