Orbit - Package Manager - Specification/ideas

[Johannes Pfau]

jdrewsen wrote:
>Den 13-07-2011 21:19, Jacob Carlborg skrev:
>> I've written a more formal specification of my ideas for a package
>> manager for D.
>>
>> https://github.com/jacob-carlborg/orbit/wiki/Orbit-Package-Manager-for-D
>>
>> Note that I am exploring the possibility of using D as the language
>> for all the files mentioned in the link above.
>>
>> The current status is that building packages and installing them
>> works, but quite limited. No dependency tracking or central
>> repository so far.
>>
>> Please comment and suggest.
>
>Nice work!
>
>Orb - tool section:
>
>Describe what the "use" command does. I guess it simply adds a
>required orb to the Orbfile in the current directory?
>
>Orbfile section:
>
>The "orb" command that accepts git/hg/svn repositories should also
>allow for a tag/commit parameter I think.
>
>The "orb" commands second parameter could also be a list of serveral 
>repositories to try in order for fallback.
>
>I guess a user configuration file in ~/.orb could contain "source" 
>commands as well.
>
>Orb package section:
>
>I think the versioning scheme should be set in stone actually. Most 
>other packaging systems does that. It makes your life much easier.
>
>Central repository section:
>
>Please let us settle for one format for the metadata.xxx file. My vote 
>is for json or yaml. XML is too verbose for my taste. I also think
>that it should be compressed e.g. metadata.json.bzip since it will
>quickly grow quite large and the packaging system has to be fast.
>Maybe add the build revision on /orb/<package>-<version>_<build>
>since it is quite common reupload the same package version with at 
>simple build fix.
>
>Additionally the architecture should be added to the name:
>/orb/<package>-<version>_<build>-<arch>
>Now it is just like how debian files look like :)
>
>Maybe put the file in an arch subdir
>/orb/<arch>/<package>-<version>_<build>
>
>I'm really in favor of doing this in D instead of ruby though.
>
>/Jonas
>
>
>
>

And in Package SubTypes:
No documentation subtype for now?
Do Library and Dynamic library always contain the .d/.di headers?

In orbspec:
The callbacks are run when the package is being build, correct? (The
install callback could also be called when the package is being
installed, but I think we don't need this functionality)
So those are the hooks to use any custom build system?

Are Check Platform and Set Platform really needed in the orbspec? I
think this can be left to drake or other build systems, can't we keep
orbspecs platform agnostic?

I'd make build_dependencies and dependencies a required field.
(Although empty is ok. Can we distinguish between not set and empty?)

-- 
Johannes Pfau