Article discussing Go, could well be D

[Jacob Carlborg]

On 2011-06-20 13:07, Russel Winder wrote:
> On Sun, 2011-06-19 at 21:19 +0200, Jacob Carlborg wrote:
> [ . . . ]
>> When I first started thinking about Orbit I decided for source packages.
>> The reason for this is that the developer only have to create one
>> package or doesn't have to build the app/lib for all supported platforms
>> when releasing a new version of the package (although it would be good
>> to know that it works on all supported platforms).
> [ . . . ]
>
> OS-level package manages have this issue, Ports went for source and
> compiling as needed on the grounds that this is most flexible, Debian,
> Fedora, etc. went for binary on the grounds it is far, far easier for
> the users.
>
> I find that most of the time MacPorts is fine as long as you only own
> one computer, but for things like Boost, MacQt, etc. my machines takes
> hours and hours to upgrade which really, really pisses me off.  I find
> Debian package far more straightforward and furthermore binary packages
> can be cached locally so I only have to download once for all 4 machines
> I have.  With source download I end up compiling twice one for each Mac
> OS X machine.  So overall source packages suck -- even though they are
> reputedly safer against security attacks.
>
> Ubuntu has introduced the idea of personal build farms, aka PPAs, which
> work very well.  This handles creating packages for all the version of
> Ubuntu still in support.  Using something like Buildbot, which although
> supposedly a CI system can easily be "subverted" into being a package
> creation farm.
>
> I guess the question is really should the package manager be easy for
> developers or easy for users?  If there are no packages because it is
> too hard for developers to package then no users either.  If developers
> can do things easily, but it is hard for users, then no users so no
> point in creating packages.
>
> It's worth noting that there is massive move in the Java arena to issue
> binary, source and documentation artefacts -- where originally only
> binary artefacts were released.  This is for supporting IDEs.  Clearly
> source only packaging gets round this somewhat, but this means
> compilation on the user's machine during install, and that leads to
> suckiness -- see above for mild rant.

Both source and binary packages have their weaknesses and advantages. If 
you have a package only available on one platform then binary packages 
would probably be the best. Maybe it's best to support both binary and 
source packages.

You mention that Java packages are getting distributed with the sources 
as well to support IDEs. For D, compared with Java, you need to at least 
distribute imports, *.di, files to be able to use libraries.

-- 
/Jacob Carlborg