2011/7/19 Jacob Carlborg <d...@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.