Article discussing Go, could well be D

[Johannes Pfau]

Jacob Carlborg wrote:
>On 2011-06-19 21:59, Jose Armando Garcia wrote:
>> On Sun, Jun 19, 2011 at 4:19 PM, Jacob Carlborg<doob at me.com>  wrote:
>>> On 2011-06-19 19:02, Johannes Pfau wrote:
>>>>
>>>> I still don't understand that completely. So does it list the files
>>>> which will be contained in the package later, or file dependencies
>>>> contained in other packages?
>>>> (I'm asking because I'm not familiar
>>>> with file-dependencies in package management systems. Most package
>>>> management systems make a package depend on other packages, but
>>>> not on the files in the packages)
>>>
>>> Ok, let me explain. When developing a package management system the
>>> first thing one has do decide is if the package should contain
>>> pre-built binaries/libraries, we can call these binary packages, or
>>> the necessary files to build the package when installing, we can
>>> call these source package (not to be confused with the source type
>>> you've mentioned below). As a third option, one could have a mixed
>>> package system containing both binary and source packages. Maybe
>>> even mixed packages could be possible.
>>
>> Why decide on "file" package? This only works with packages that can
>> be compiled. Think non-D source code packages and close source
>> packages. Even one of the most commonly known "file" package manager
>> (Gentoo's portage) allows for binary packages.
>
>I guess we could have a mixed system, with both source and binary
>packages.

Definitely. Standardised source packages allow automated binary package
building, even for different architectures. Users should also be able
to make small changes to source packages and create their own binary
packages easily. Source packages only wouldn't work either, think of
users on embedded systems. Compiling everything on a machine with 16MB
ram and 200mhz isn't fun. Also binary packages are quite convenient.

-- 
Johannes Pfau