www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - dlang-dockerized: Summer 2026 Status Update

reply Mindy Batek (0xEAB) <desisma heidel.beer> writes:
Hi,

It’s been a while since the last time I wrote about the 
dlang-dockerized project on the newsgroup. Given that a few 
notable changes have happened (or are planned to be made happen — 
depending on the angle you look at it), I felt justified to 
provide an update.



I’ve finally been able to allocate a bit of time to work towards 
upgrading the Containerfiles (or “packaging scripts”) to work 
with Debian 13 “Trixie”. I’m quite late, I have to admit, but 
truth to be told, it does not really matter. If anything, an 
older base-image provides broader compatibility. Anyway, I’ve 
tested things and reached a point where I’m confident that things 
work the way they should.

My current plan is to rebuild the “Bookworm” images of 
dlang-dockerized with the latest base images and push them to the 
registries — ghcr.io and docker.io — by the end of the month.

Then in August, I’ll finally publish “Trixie”-based images.



If there’s been one thing that the project was lacking since the 
begining, then that has probably was sustainability.

My original goal was so overambitious that reality quickly made 
me give in. While I started out with the idea to package all 
compiler versions since the switch of C++ to D, compatibility 
issues (especially at link time) and numerous breaking changes to 
the build process brought me back down to earth quickly.

While the reduced number of supported compiler versions — and a 
much smaller selection of actually published images — I still had 
a large number of different configurations to maintain, test and 
build.

A recent change, something that I had been planning to do for 
quite a while now, — namely to also build LLD (LLVM-based linker) 
as well as LLDB (LLVM-based debugger) — I quickly ran into 
further challenges stemming from the large combination of 
different software versions. As much as I regret pruning the list 
of “supported” versions, I have to admit that I never really had 
the time to bother about maintaining things properly and 
thoroughly.

As I set out to make amends for that, it became clear that I had 
to reduce the maintenance coverage quite a bit.

Nevertheless, these changes also allow me to publish an actual 
maintenance policy for users to count on. At least to the extent 
outlined in that policy — after all, I’m still a single volunteer 
taking care of those tasks in my spare time.

<https://github.com/dlang-dockerized/packaging/blob/c5f45a320992715acff5507638f7535225f5981d/MAINTENANCE.md>

In addition to the reduction in required maintenance afford, the 
new policy also brings down the compute cost for building 
container images to publish. The gentle reader might already be 
aware, but compute resources are kinda expensive these days due 
to steeply rising hardware prices.



There’s another victim of this new policy change. And one that 
may actually hurt a bit. In order to keep the maintenance 
overhead low, all upcoming changes are only applied to the new 
“Trixie” branch and won’t be backported to the “Bookworm” one.

Hence maintenance of the “Bookworm” branch is ending by end of 
the month. But don’t worry, the published bookworm-based images 
will stay available as-is. And users can just write a 
Containerfile that uses a legacy image for building and copies 
over the resulting binaries into an up-to-date Bookworm image. 
Additionally, the legacy Containerfiles can still be found in the 
Git repository and be built by users on their own.

However, I’m looking forward to maintaining the “Trixie” branch 
for quite a bit longer than the “Bookworm” one. Whether or not 
there will be corners to cut in the future… Who knows? I’ll 
attempt to maintain this branch as long as reasonable — which 
will hopefully be as long as the LTS period of the OS.



It follows herefrom that dlang-dockerized no longer plans to 
support Alpine/musl as base-image. Neither are there any plans to 
support the Enterprise Linux family of distros. Support for 
xtensa’s fork of LLVM is discontinued. (Never published any built 
images with that anyway.)

Special thanks to my fellow packagers who take care of 
maintaining different kinds of container images. Given the 
aforementioned scope reduction of dlang-dockerized, I find these 
options in particular noteworthy to mention:

- Alpine images by Matheus: 
<https://github.com/kassane/alpine-ldc2-docker>
- Xtensa stuff by Jonas: <https://github.com/jnms-me/packaging>

For the time being, dlang-dockerized’s support is limited to 
Debian derivatives — and even that on a non-committal basis with 
no promises. (If someone needs commercial-grade support, I’m 
confident they’ll know how to arrange that.)

I’m pretty sure that recent changes to the build process — in 
particular the admission of LLD and LLDB to the build process — 
will require further adaptions for “Ubuntu”-based images. I plan 
to look into that, but there’s no ETA. While Ubuntu is not 
covered in accordance to the maintenance policy, it is one of the 
most prominent Debian derivatives and as such I may consider it 
worthy from time to time to fix compatibility issues should they 
arise.

Nevertheless, my general recommendation is to use the 
Debian-based images for building then copy the resulting binaries 
into a another one. Such multi-stage builds are a well-supported 
practice.
There’s no need to ship a compiler with your application ;)



It has been pointed out by community members that searching for 
D, DMD, LDC or dlang on Docker Hub brings up not a single image 
with a “trusted content” badge (i.e. “Docker Official Image”, 
“Verified Publisher” or “Sponsored OSS”).

While the first category is a bit inaccessible due to their 
policies


 We expect and require a commitment to maintain your image 
 (including and especially timely updates as appropriate, as 
 noted above).


… the second one could work if a commercial entity were to step 
up. Last but not least, our most realistic option would be to 
apply for “Sponsored OSS”.

Most importantly, that would lift the ratelimits free users on 
Docker Hub are subject to.



The official downloads page on dlang.org currently links an 
unmaintained and outdated compiler image.

While I cannot restore the love for D its maintainer had in the 
past before getting fed up with lead maintainer decisions, I can 
restore Docker-support by proposing to replace that link with 
dlang-dockerized.
See: <https://github.com/dlang/dlang.org/pull/4455>

Best regards,
Mindy
Jul 27
next sibling parent Sergey <kornburn yandex.ru> writes:
On Tuesday, 28 July 2026 at 01:38:08 UTC, Mindy Batek (0xEAB) 
wrote:

 Hi,

 Best regards,
 Mindy


Thanks!
I would like to also mention 
https://hub.docker.com/r/vreitech/docker-ldc
As this image contains some extra libs that allow to use LTO for 
LDC
Jul 27
prev sibling parent Mindy Batek (0xEAB) <desisma heidel.beer> writes:
On Tuesday, 28 July 2026 at 01:38:08 UTC, Mindy Batek (0xEAB) 
wrote:



 There’s another victim of this new policy change. And one that 
 may actually hurt a bit. In order to keep the maintenance 
 overhead low, all upcoming changes are only applied to the new 
 “Trixie” branch and won’t be backported to the “Bookworm” one.

 Hence maintenance of the “Bookworm” branch is ending by end of 
 the month. But don’t worry, the published bookworm-based images 
 will stay available as-is. And users can just write a 
 Containerfile that uses a legacy image for building and copies 
 over the resulting binaries into an up-to-date Bookworm image. 
 Additionally, the legacy Containerfiles can still be found in 
 the Git repository and be built by users on their own.


It’s time to say my goodbyes… The final round of bookworm-based 
container images has been built and pushed to both registries.

Farewell Bookworm, trusty old friend!
No fear. Trixie will follow in your footsteps.
Aug 01