SoC: current status (Elias Pipping)

[Elias Pipping]

Hi,

here's the status:

merge.rb is a tool that's designed to merge an arbitrary amount of
single-architecture directory-trees into a single universal tree.

So, given the Coreutils scenario we have four directories - ppc, ppc64,
i386, and x86_64, each holding a destroot whose architecture matches
its name.  Here's where merge.rb comes into play. It's invoked via

  merge.rb ppc ppc64 i386 x86_64,

you can pass an architecture more than once (doesn't matter) or leave
one out (does matter), pass -v or --verbose for verbose output, perform
a dryrun, change input and output directories, etc.

That's all documented[1].

There are also a couple of test cases, among them Coreutils, the others
include OpenSSL and LibPNG - again, all documented[1].

merge.rb is written in Ruby.

That's a good thing because it makes the code easy to read (even if one
does not know Ruby at all) and maintain.  The code is concise, flexible
and extensible.

It's not a bad thing because it does not (need to) use MacPorts internals,
it could even be used if MacPorts was completely rewritten and none of
its current API remained.

I've set up a separate subversion repository[2] for merge.rb, from time
to time I also sync it with /users/pipping in the MacPorts repository.

The code is made available under the MIT license.[3]

[1] merge.rb's wiki: http://elias.binera.de/dokuwiki/doku.php
[2] merge.rb's repo: http://elias.svn.binera.de/bin/cgi/viewvc.cgi/
[3] merge.rb's license: http://www.opensource.org/licenses/mit-license.php

======

Up until now I've been working on merge.rb; I think it does what it's
supposed to do and it does it well.  Testing is appreciated.

If you've been asking yourself where those 'ppc', 'x86_64', etc.
directories are supposed to come from, that's part two.

merge.rb could run on a server, clients could upload their trees (built
via MacPorts) to the server, etc. - the infrastructure needs to be
controlled/used somehow.

There are a lot of open questions and that's why I'm asking for
feedback.

Given merge.rb would run on a server, how would it communicate/interact
with clients? Who would initiate merges or what would they be triggered
by, etc.  What would you want to be able to do with it?

Looking forward to hearing your ideas.


Kind regards,

Elias Pipping