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

Matthias Klumpp via Digitalmars-d digitalmars-d at puremagic.com
Mon Apr 10 05:59:37 PDT 2017


On Monday, 10 April 2017 at 12:40:33 UTC, Vladimir Panteleev 
wrote:
> On Monday, 10 April 2017 at 11:40:12 UTC, Matthias Klumpp wrote:
>> Recompiling the dependency-chain of a software from source 
>> when compiling a package using the "right" compiler and 
>> statically adding the code is forbidden by distro policy.
>
> This is the part that I do not understand.
>
> Who came up with those policies and decided that they apply to 
> D? Because I really don't think they should.

They are the result of years of experience in building complex 
systems and keeping them secure.
If you have a dependency chain "X -> Y -> Z" (-> meaning "depends 
on"), and you find a security bug in Z, you the security team 
will just need to fix the bug in Z to resolve it in the whole 
distribution.
But if the code which has this issue is compiled into all of the 
packages that depend on them, you will need to rebuild the full 
dependency chain to actually fix the security issue, which is not 
only time intensive but also a huge maintenance effort.
In this simple example it doesn't look like much, but those 
dependency chains can grow massively large and complicated, and 
the only way to keep the large software stack maintainable and 
secure is by splitting pieces cleanly.

Embedded code copies are allowed in rare events, but in these 
cases the security team needs to be aware of them.
Sometimes, the licenses also explicitly prevent embedded code 
copies.

Aside from these issues, splitting things cleanly also makes 
general package maintenance much easier, and adds flexibility for 
our users who can mix and match parts of the distribution as they 
like and combine them with their own code.

You need to see here that D is not the center of the world and we 
will need to make it work nicely with the rest of the system. The 
technical policies work for everything else, so there is nothing 
that really justifies an exception for D here (if 10% of Debian's 
code was written in D and the Debian D team was really large we 
could maybe get one, but not the way it is now).
And tbh, I think finding a good solution here is entirely 
possible.


More information about the Digitalmars-d mailing list