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
On Jul 22, 2007, at 9:35 AM, Elias Pipping wrote:
merge.rb is a tool that's designed to merge an arbitrary amount of single-architecture directory-trees into a single universal tree.
Sounds great.
The code is made available under the MIT license.[3]
Why choose an MIT license when the rest of the MacPorts tree is BSD licensed? The two licenses are functionally equivalent, but it's ideal to have unified licensing terms wherever possible. - Kevin
On Jul 22, 2007, at 9:35 AM, Elias Pipping wrote:
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.
Why keep it in a separate repository? It's one more place to look for the code. Regards, Blair
On Sun, Jul 22, 2007 at 07:31:10PM -0700, Blair Zajac wrote:
On Jul 22, 2007, at 9:35 AM, Elias Pipping wrote:
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.
Why keep it in a separate repository? It's one more place to look for the code.
I chose a separate repository (and wiki) for a number of reasons: * I do not like working with Trac (contrary to ViewVC and DokuWiki - If I had needed a bug tracker I would have set up BugZilla, too) * I did not want to spam MacPorts-Changes with my commits to merge.rb needlessly. * A separate repository makes it very easy, regarding the SoC, to say what I wrote - maybe it was easy already, but now it's trivial. Kind regards, Elias
On Jul 23, 2007, at 02:09, Elias Pipping wrote:
I chose a separate repository (and wiki) for a number of reasons:
* I do not like working with Trac (contrary to ViewVC and DokuWiki - If I had needed a bug tracker I would have set up BugZilla, too) * I did not want to spam MacPorts-Changes with my commits to merge.rb needlessly. * A separate repository makes it very easy, regarding the SoC, to say what I wrote - maybe it was easy already, but now it's trivial.
This looks neat, but seems to be an independent set of scripts, rather than anything integral (or intended to be integral) to MacPorts: - You used a different language - You used a different license - You used a different source repository and wiki Which doesn't sound very integrated =) -landonf
On Mon, Jul 23, 2007 at 02:05:44PM -0700, Landon Fuller wrote:
On Jul 23, 2007, at 02:09, Elias Pipping wrote:
I chose a separate repository (and wiki) for a number of reasons:
* I do not like working with Trac (contrary to ViewVC and DokuWiki - If I had needed a bug tracker I would have set up BugZilla, too) * I did not want to spam MacPorts-Changes with my commits to merge.rb needlessly. * A separate repository makes it very easy, regarding the SoC, to say what I wrote - maybe it was easy already, but now it's trivial.
This looks neat, but seems to be an independent set of scripts, rather than anything integral (or intended to be integral) to MacPorts: - You used a different language - You used a different license - You used a different source repository and wiki
Which doesn't sound very integrated =)
merge.rb is what the wiki, etc. are all about, everything else in the repository is tests that create environments merge.rb can be tested in. merge.rb was not meant to be integrated into the 'port' command, which is why using a different language is not a problem. I did not mean to impose a barrier by choosing another license and I think I did not - the MIT and the BSD license are perfectly compatible and I don't see why mixing them would cause any problem. I think merge.rb should utilize MacPorts and not the other way around, which would also allow it to be used by other package managers or even completely without a package manager (as demonstrated by the test scripts). That also means that I would not want it (to be required) to be `integrated`, which, the way I see it, is *not* a bad thing. It only means that others can profit from merge.rb and do not need to reinvent the wheel over and over again. Kind regards, Elias
participants (4)
-
Blair Zajac
-
Elias Pipping
-
Kevin Van Vechten
-
Landon Fuller