Phil Tomson (ptkwt / shell1.aracnet.com) wrote: > Can sombody(s) do a quick compare and contrast of rpkg and rubynet? > Sounds like rubynet has more requirements (XML parser, etc.) which is a > bit worrisome since we would like whatever packaging system to work 'out > of the box' (though I think I've heard that REXML will be included in 1.8, > did I hear correctly?) Here's a quick comparison. I'm going to go over the requirements, advantages, and struggles of each project quickly, as far as I can see from information publicly available on the web. Hopefully the developers on each project can help clarify. 1. Software requirements: rpkg requires zlib. [http://www.allruby.com/rpkg/usage.html#AEN4] rubynet requires ruby-libxml, ruby-libxslt. [http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/rubynet/rubynet/WORK?rev=HEAD&content-type=text/plain] Running a rubynet server also seems to require quite a bit: *) A good network connection *) A unix server *) postgresql 7.2.1+ *) ruby *) ruby-dbi *) ruby-dbd_pg *) ruby-libxml* *) ruby-libxslt* *) fping (ftp://ftp.stanford.edu/dept/networking/pub/fping/) [http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/rubynet/rubynet/REQUIREMENTS?rev=1.2&content-type=text/vnd.viewcvs-markup] 2. Project ideals: rpkg 1. Modeled after Debian's apt. 2. Command-line tool for: a. searching online repository for current modules b. downloading, installing, and removing archives 3. .rpk files can be distributed offline 4. Few steps to build a package: a. Create directories for binary files, docs, unit tests, library files. b. Create an RPKG/control file: Package: foo Version: 0.0.1 Section: net Priority: optional Architecture: all Depends: Conflicts: foopkg-beta Replaces: foopkg-beta Maintainer: Mr. Maintainer <foo / bar.com> Source: Description: A foo package Everything here is the long description. Every line must be indented by one space. . Blank lines are not allowed, use a point as in the line above. c. rpkg --build foopkgdir rubynet 1. Inspired by CPAN and FreeBSD ports collection, but seems to be its own creature. 2. Command-line tool for: a. searching online repository for current modules b. downloading and installing archives c. creating new archives --create would take the XML file for the module and create the actual module/package. The module should be a gzipped XML file with the maximum compression (done via libxml). shared objects or other binary pieces of data should be MIME64 encoded before being included in the XML file (should be a simple call to pack()). 3. rubynet_require 'module_name' 4. Rubynet appears to mandate some sort of structure for peer review of packages and documentation, though I don't know where there are specifics as to how this works. [http://rubynet.sf.net/] 5. "dot rubynet" files describe a package: a. A package maintainer has all of these files, containing key-value pairs: .rubynet_author(_*)? .rubynet_build .rubynet_categories .rubynet_dependency(_*)? .rubynet_files .rubynet_libs .rubynet_project .rubynet_test [http://rubynet.org/apps/rubynet/] b. Which are compiled into XML. "I haven't documented really how this fits into the whole build process, but suffice it to say that developers/users will edit various dot files described in the below spec which will then be compiled into the rubynet module file (a compressed XML file). The only dot file that I'm not happy with or want to rework is the .rubynet_files file. The .rubynet_files contains the packaging list for an installed module and not the list of files that are to be included in the rubynet package (the files section of the rubynet module... think of it as the list of files that you'd want to tar up if had to package up your module)." [http://lists.rubynet.org/lists/pipermail/rubynet-devel/2002-October/000188.html] 3. Thoughts/Concerns rpkg 1. This project is great because it's simple. It could be mirrored and implemented right now without tremendous pain. 2. Currently only distributes Linux binaries. 3. Could use man pages, more options in the CLI, better interfaces for access the repository from Ruby. 4. The project doesn't seem to have a clear plan for mirroring. rubynet 1. This project is VERY precocious. And it's also quite young. They are just beginning a long process and are still in the planning stages. I would say a useable rubynet is two years out. Not to mention that many of the developers are wrapped up in other time-consuming projects. 2. This project could be tremendous. 3. This project could be a mess. 4. My ultimate thought after looking at rubynet was: why aren't they teaming up with rpkg/rapt? rubynet is tackling the same issues as rpkg/rapt with very few advantages to their packaging approach. Why don't these two teams get together and have rapt/rpkg work on the packaging system, while rubynet works on the infrastructure? 5. Rubynet on rpkg: "Aren't there other Ruby package management systems out there? Yes, there is one other one that we know about called rpkg. However, we believe Rubynet will be quite different then rpkg. Rubynet is a service based system allowing clients to query Rubynet for a vast variety of information aside from just packages. The Rubynet services available will be published allowing new clients to be written independent of the Rubynet project." [http://216.239.53.100/search?q=cache:E9ZNTmfltYwC:www.rubynet.org/+rubynet+rpkg&hl=en&ie=UTF-8] 4. Verdict: Rubynet could use rpkg's simplicity. Rpkg could use some of rubynet's complexity. _why