On 2011-07-13 22:20, 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?
I'm not sure if this is possible or not (specially on multiple
platforms) but I was thinking something like this:
Say that you have several versions of the dwt package installed and you
want to use a particular version, you can run the command like this:
"orb use dwt --version 0.3.5"
Then when you link with the "dwt" library it will link with the 0.3.5
version.
Orbfile section:
The "orb" command that accepts git/hg/svn repositories should also allow
for a tag/commit parameter I think.
Absolutely.
The "orb" commands second parameter could also be a list of serveral
repositories to try in order for fallback.
That might be a good idea.
I guess a user configuration file in ~/.orb could contain "source"
commands as well.
Sounds reasonable.
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.
So you mean I shouldn't allow custom version strings?
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.
I haven't actually thought about what format to use. I just listed a few
reasonable formats. Settling for one format is probably a good thing.
Probably json since both Phobos and Tango has json modules and it's
available in most languages.
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.
If you read the version scheme I was thinking about having the last
number as a build number:
major.minor.build
* Increment "build" when an implementation detail change
* Increment "minor" when a non-braking API change is made, i.e. adding a
new function
* Increment "major" when a braking API change is made, i.e. removing a
function
Maybe there should be a patch level of some king as well and alpha, beta
and release candidates as well.
Additionally the architecture should be added to the name:
/orb/<package>-<version>_<build>-<arch>
Now it is just like how debian files look like :)
Hm, this will take some though. I don't like the idea that the developer
has to create multiple packages for a single package.
Maybe put the file in an arch subdir
/orb/<arch>/<package>-<version>_<build>
That is probably better.
I haven't actually thought that much about binary packages. I was mostly
thinking about source packages that need to be built when installing
them. Source packages don't have these problems.
I'm really in favor of doing this in D instead of ruby though.
/Jonas
I guess most people are.
--
/Jacob Carlborg
