This is a list of issues found while making the D ecosystem available on Linux distributions such as Debian and Fedora. It is a smaller, but priorized list of the general list of issues I find while working with D that can be viewed at dlang-quirks.md.
This list is ordered by priority, more pressing issues being at the top.
-
D has no stable ABI. This kind of enforces recompiling all D shared libraries and binaries in a Linux distribution with every new compiler version. This is possible, but a major pain which requires quite some amount of manpower (Debian does this for OCaml and Haskell) - getting people to use D if it is that much extra work is harder. It also means that you can not use the libraries which were compiled with LDC in an application that is compiled with GDC and vice versa. This is a real PITA for distros and users who might have binaries compiled with the "wrong" compiler. It reduces the usefulness of development D packages in distributions a lot, if you need to recompile everything again anyway. Static linking is also frowned upon by distributions, because it triggers rebuild cascades on every bugfix that we introduce, making devlivering security updates much harder and error-prone (embedded code copies are very difficult to handle). A stable D ABI, or at least a guarantee that the ABI will not change unless there is a good reason (and the ABI change will be announced in the release notes) would help a lot. Having a D ABI that is shared between DMD, LDC and GDC would be even better.
-
Dub doesn't use packages installed to system locations (dlang/dub#838) - this renders dub pretty much unusable for using it as part of the Linux distribution package tooling. Dub also writes into
$HOME
as part of the build process which is considered bad practice and is disallowed on build daemons at Debian (you need to add a hack for tools which expect$HOME
to be available) -
Dub: Can not version dependencies on other libraries (dlang/dub#906) - this makes it hard to determine compatibility if we package software written in D.
-
dub test
overrides the binary created bydub build
(prevents automatically running tests as part of the build process) (dlang/dub#840) -
No working Make/Ninja compatible depfile generation in LDC, DMD or GDC - this is especially important when not using dub (see the dub issues) and some other build system (Automake/CMake/Meson/..) is used instead. See ldc-developers/ldc#1802 for the LDC bug report.
-
There is no
dub install
command (dlang/dub#839) -
LDC doesn't support a lot of architectures / architecture support breaks from time to time. It would be quite nice to have D tools available on as many architectures as possible. (see ldc-developers/ldc#1636 for a bug report, build logs are here: https://buildd.debian.org/status/package.php?p=ldc)
The GDC issues have been separated out to not clutter the priorized overview.
-
GDC is not part of official GCC. This makes it difficult (or actually sometimes impossible) to ship it with some Linux distributions, e.g. RHEL and Fedora. On Debian, we inject GDC into the GCC build, which is also a bit weird. Having GDC in GCC proper would also give D much higher visibility.
-
GDC only supports an ancient version of the D standard library, which has many nice classes and also bugfixes missing. Because of that, it is almost impossible to compile modern D applications with GDC, and when developing a new application, support for GDC needs to be added explicitly and handled with a lot of care. This is an issue LDC doesn't have, and which is fragmenting the D ecosystem.
-
GDC does not support creating shared libraries at time, which is a big deal for distros which need it to reduce duplicate code and make security fixes easier.
- DMD is completely free software now, there is no obstacle to ship it in distributions anymore.
The Debian D team could use a lot more manpower to update things like this and modernize the tools it uses... TBH, I think with just a few small tweaks to dub, packaging D code should be even nicer than packaging Rust code - D has everything there, even Meson integration, and Debian's tools have evolved. LDC is also truly excellent as a compiler now, it is less of a pain than it was before.
With GDC we even have a D compiler pretty much everywhere now (unfortunately GDC still can't compile a lot what LDC can).
Writing to
HOME
is not an issue, but being unable to disable that is what the problem is - writing stuff to HOME introduces state, which is not what we want when trying to reproducibly build packages.So, many modern package managers either have the option to disable that, write to a temporary location, or at the very least don't fail if HOME is inaccessible (which it deliberately is on package autobuilders). Some do have the option to deflect HOME to a different place, like cargo with the
CARGO_HOME
environment variable that Rust builds in Debian just set to a temporary location.Indeed, and we do have the tools now to handle static builds across many packages - it's highly automated to do cascade rebuilds.
A way to make dub use a temporary location other than HOME, either by an env var like
CARGO_HOME
which sets a location, or just by a variable likeDUB_USE_TMP_HOME=y
where it uses a location in /tmp would be nice. Also, a way to load packages from a standardized system location (/usr/share/dub/<package>-<version>
?) and a standardized command to install them there would be extremely nice - also, dub must not try to write into those locations, of course. Apart from that, I don't think there's much we would need (we could even setHOME
already to fool dub, but that is a pretty messy approach).In general I think the most helpful thing is standardization: If dub has standard system locations where it loads from, and there's established ways how D projects handle things, it will be super easy to write tooling to wrap them in packages (of course, someone would still need to do that - I do have a lot less time currently (and the "D time" is use on e.g. updating LDC), but I definitely could sponsor new packages into Debian if someone else worked on them).