The D ecosystem in Debian with free-as-in-freedom DMD

[Matthias Klumpp via Digitalmars-d]

On Monday, 10 April 2017 at 14:21:43 UTC, Gerald wrote:
> On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
>> There are a two issues though that we will be facing in Debian 
>> soon, and I would like to get some opinion and maybe 
>> perspective on from the D community on them.
>
> First I would like to say thank you for all the work you did in 
> getting Tilix packaged for Debian, it is very much appreciated. 
> While I'm not an expert in this topic I'll throw in my two 
> cents anyway :)

Thanks!

> So to the topic at end, I tend to agree with Vladimir in that I 
> just don't see it as feasible to make every dependency a shared 
> library. Personally I would suggest that only libphobos and 
> libdruntime be managed as shared libraries by a distro. 
> Otherwise, any other dependencies used in DUB or elsewhere 
> would be statically compiled.

This would raise the maintenance effort for D software, and 
require policy exceptions, which is something we won't do. It's 
more likely that we'll see less D in the distro than going down 
this route.
DUB is unusable for Debian packaging anyway, and alternatives 
like Automake or Meson handle shared libraries really well, so in 
itself there is no reason not to do it.

> If in time a new D library ends up becoming a keystone 
> foundation for many packages it could be considered for 
> inclusion as a shared library. Otherwise, trying to manage 
> every DUB dependency as a potential shared library is a huge 
> amount of work and I don't feel most of them are mature or well 
> maintained enough to support this approach.

We'll take care of that, it's what we do as a distro and we have 
a fair amount of experience in handling these kinds of upstream 
projects.
The goal is to reduce the maintenance cost for things once they 
are *in* the distro, any prior work to get it into the 
distribution is very well invested.
That's why I have been writing a lot of Makefiles and Meson build 
definitions lately.

> If you just concentrate on compiler, libphobos and libdruntime, 
> you can have separate packages for each compiler toolchain 
> which was Arch does.

That's a necessity already and we do the same. But with an 
unstable ABI the standard library is also affected, which would 
trigger us to do Haskell-style versioning (which mangles 
dependencies to depend on a virtual package containing a hash of 
the GHC version), and that not only sucks but also requires quite 
a lot of manpower.

> It has a libphobos package for DMD and a liblphobos for LDC. 
> This then enables developers to specify the tool chain they 
> prefer without interference.

Yes, but that's not feasible for use *in the distribution itself* 
as we can't just pick and choose the right compiler per package 
if something up in the dependency chain was compiled with the 
"wrong" compiler.

> In addition to the question about D and C++. what do distros 
> typically do for Rust and Cargo dependencies, or Java and 
> Maven? Wouldn't that be a similar paradigm to D and DUB 
> dependencies?

Maven dependencies are also separated out into smaller packages 
and maven (unlike dub) plays relatively well with Debian. It also 
has no ABI issues and interface stability can be tracked. Rust 
only has one compiler which strongly optimizes, so we don't have 
the problem of choosing the right one. Cargo is/was an issue but 
it's being worked on and seems to work well now: 
https://wiki.debian.org/Teams/RustPackaging/Cargo
(not that I am not involved in Haskell, Rust or Java packaging).

Just because it makes sense: We do have an upstream guide showing 
some best practices for upstream projects which help us to 
maintain software for long periods. It also contains 
language-specific advice and some general info which is valid for 
all languages:
https://wiki.debian.org/UpstreamGuide