Dream package management system (Was: a cabal for D ?)

[Chris Manning]

On 19/03/2011 14:36, Jacob Carlborg wrote:
> On 2011-03-18 18:04, Chris Manning wrote:
>> On 17/03/2011 22:49, Jason E. Aten wrote:
>>> Somewhat tongue in cheek, we could call it dabal.
>>>
>>> As in, "get on dabal!" :-)
>>
>> If D gets accepted for Google Summer of Code, I think this would be a
>> great idea for a project and I would be interested in implementing it as
>> a student. Although, it does seem overly ambitious so maybe only some of
>> this could be for the gsoc (and if I do this It'd be great to carry on
>> working on it anyway).
>>
>> What does everybody think about this? Should I draw up a proposal of
>> some kind?
>>
>> Chris
>
> I've been thinking for quite some time to build a package management
> system for D, lets call it dpac as an example. This is the ideas that I
> have:
>
> Basically copy how RubyGems works.
> Use Ruby as a DSL for dpacsepc files which is used to create to create
> the dpac file. This is an example for how a file used to build a package
> could look like:
>
> name "Foo Bar"
> summary "This is the Foo Bar package"
> version "1.0.0"
> type :lib
> author "Jacob Carlborg"
> files ["lib.d"] # list of the files in the package
> build :make # other options could be :dsss :cmake and so on
> dversion 2 # D1 or D2
>
> Build a dpac package out of the dpacspec file:
>
> dpac foobar.dpacspec
>
> Publish the package:
>
> $ dpac publish foobar
>
> Install the package:
>
> $ dpac install foobar
>
> A dpac package would just be a zip file (or some other type of archive)
> containing all the necessary files to build the package and a file with
> meta data.
>
> All packages would be manged on a basic RESTful web server. Using GET to
> download a package and POST to publish a package.
>
> I'm working on a build system for D that I was thinking about to
> integrate with the package management system. Then the build system
> could track the files needed to build the package, making the "files"
> attribute optional.
>
> I also has a tool called DVM, https://bitbucket.org/doob/dvm , used for
> installing and managing different versions of D compilers. I was
> thinking about integrating DVM with the package management system to be
> able to install different packages for different compilers.
>
I was thinking about something more similar to portage's ebuild system 
or arch's AUR. This would mean that the sources could be stored anywhere 
and just the info to build a package would be stored in a centralised 
location.

For publishing these build "scripts", again, AUR's system comes to mind, 
although perhaps something more controll(ed/able). Also, gentoo's 
sunrise overlay.

Of course, this comes with the downside of the user having to compile 
the packages on their end.

Chris