Prototype buildsystem "Drake"

[Ulrik Mikaelsson]

2011/7/19 Jacob Carlborg <doob at me.com>:
> On 2011-07-19 16:46, Russel Winder wrote:
>>
>> There is clearly a string coupling between configuration and package
>> management.   Autoconf, Waf and SCons have to be portable across package
>> management since they are not dedicated to one scheme -- springing up as
>> they did from before package management as standard.
>
> Ok.
>
>> There are some potentially tricky issues here.  Ruby gets round it by
>> having a language specific package and build system which therefore
>> causes Debian, Fedora, FreeBSD, Macports, Fink, etc. packagers massive
>> headaches.  Haskell/Cabal, Python/Eggs, etc.  The conflict between
>> language packaging and platform packaging is central.  Having a D
>> language packaging system that was in some way harmonious with Apt/Deb,
>> Yum/RPM, Ports, etc. would make a lot of people very happy.  Indirectly
>> it would make traction a whole lot easier.  As evidence I present Java,
>> Ruby, Python, Haskell, etc.
>
> The whole point of having a D package manager is so I don't have to create
> packages for all these system specific package managers.

In my experience with gem and easy_install, it's not really practical
for the end-user. After several attempts, I always ran into problems.
Especially library-bindings in the language-specific package-manager
tends to conflict with what library is installed in the system,
causing problems. In all the cases I ended up biting the bullet and
create a OS-package for the Python/Ruby packages we're using in
production. I've later learned the experience is shared with others, I
know one company who even went back to .NET due to too much hassle
with Ruby On Rails deployments (gem), and I suppose
distribution-developers wouldn't put as much effort into packaging all
the Python and Ruby-packages they do if not others had seen problems
with per-language packagers.

Especially, if D is to gain traction and attract developers, getting
proof-of-concept applications out in the respective "app store" of the
target OS:es is quite important, which requires working with the
native packaging format.