PLD Ruby plans

Ruby’s packages in PLD are decent (I made most of them), but there’s some nasty quirks around ri because it doesn’t play nice with RPM: a package that adds methods to a core class like Array generates a new cdesc-Classname.yaml file, which would require a programatic merge (and worse, unmerge) from the installed copy. This isn’t acceptable, because it makes MD5 checksum verification much more fragile, which is one reason people use an RPM-based system: the validity checks are powerful when the packages are made right.

I’m planning on doing several things to PLD’s ruby packaging in the coming time:

  • Package setup.rb as a package in its own right, for build scripts to draw on. I have a copy in CVS right now, but I’m manually synching it with upstream, and there’s no versioning that way. Now, I can declare which version of setup.rb I coded the package spec against, so that when I update setup.rb, I’ll know what packages have to be updated to match, since there are no backward-compatibility guarantees.
  • Patch ri to use more than one YAML file for its class description format. Or maybe scrap it entirely since ri is amazingly slow, when compared to man(1).
  • Make a new, less ugly and more useful and easier to index RDoc template.
  • Perhaps centralize ruby docs into /usr/share/doc/ruby/{core,stdlib,packagename}, for easy mass-publishing to the web, since most docs require a browser to read effectively.
  • Package some of the Heretix system administration scripts, to toy with at least.
  • Pipe dream: find an effective way to replace init(8) and rc-scripts with ruby, and make the boot sequence faster and better organized.
  • Code a nice full-text index to the installed documentation, and an XMLHTTPRequest-based UI for it, for efficient searching of the entire installed set of package docs.
  • Patch Ruby (or maybe just Ruby’s build) to look for architecture-independent libraries in /usr/share instead of /usr/lib{,64}, so that noarch packages can be built, and are actually the same when built on all architectures. Sparc64 and AMD64 are problematic in that there is both a /usr/lib and /usr/lib64, but Ruby only looks at the one it was built with, and in /usr/share not at all.