Official dub packages for Debian and Ubuntu

[Matthias Klumpp via Digitalmars-d-announce]

On Friday, 15 April 2016 at 09:15:05 UTC, Johannes Pfau wrote:
> Am Thu, 14 Apr 2016 23:16:49 +0000
> schrieb Matthias Klumpp <matthias at tenstral.net>:
>
>> On Thursday, 14 April 2016 at 17:46:55 UTC, Johannes Pfau 
>> wrote:
>> > OSS projects do not use interface files though: It prevents 
>> > inlining of functions and there's no real benefit for OSS 
>> > projects. Interface files are (theoretically) useful for 
>> > closed source libraries if you don't want to ship the source 
>> > code.
>> 
>> I think those would also be useful for FLOSS projects, if you 
>> ship a compiled binary and don't want to recompile the code. 
>> This is the case for example for very huge projects which take 
>> long to compile (think in WebKit or Eigen3 dimensions), or for 
>> Linux distributions which want to separate as much code as 
>> possible and prevent code duplication and statically linked 
>> stuff to make security uploads easier and faster.
>
> I totally agree it makes sense to ship precompiled libraries. 
> But even with precompiled libraries you can still ship the full 
> source code instead of header files. An example:
>
> [...]
>
> The important point here is that you can use the normal source 
> code as headers. The source code of a library is not 
> recompiled, it's only used to parse function definitions and 
> similar stuff. The compilation speed should be very similar for 
> .d and .di files as well. The benefit of shipping the complete 
> source code is that fooFunc can be inlined into main.d with the 
> foo.d source, but not with foo.di.
>
> Shipping .di files only makes sense if you have to hide the 
> source code.

Or when the source-code is very large, I guess. But the way D 
handles this makes much sense to me!

>> [...]
>
> I agree having a common ABI should be prioritized. It's really
> annoying for distributions (E.g. archlinux installs 
> druntime/phobos into
> different directories /usr/include/dlang/{gdc,dmd,ldc} and never
> installs compiled libraries). Shared D libraries are useless in
> practice because of this issue.

Yeah, and this makes D pretty hard to sell to distributors. While 
I would argue that for applications it is no longer essential to 
be packages and shipped by distributions (or rather it won't be 
in future), for a "new" programming language this is a crucial 
thing.
As soon as it is easy to try out for developers, more people will 
"just try it" and maybe stick with it. If testing it is hard due 
to incompatible standard libraries, runtimes, or simply missing 
free D compilers, people won't try it.
In fact, that it also is pretty hard for people to compile 
applications written in D on distributions other than Debian (and 
even there it was not without issues...) was *the* biggest 
concern for me.

> This needs coordinated work from all compiler teams though. For 
> GDC I'll finally have to finish shared library support first...

That would be awesome to have! Thank you for working on this!