Log in

No account? Create an account

Previous Entry | Next Entry

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.


( 6 comments — Leave a comment )
Jun. 25th, 2005 10:28 am (UTC)
Why the drop into monospace halfway through the list?
Jun. 25th, 2005 10:39 am (UTC)
A forgotten </code>. Guess who forgot to validate before sending.
Jun. 25th, 2005 10:40 am (UTC)
Kudos to Safari for actually breaking. Gecko silently fixes it in the rendering.
Jun. 25th, 2005 12:29 pm (UTC)
ri patches to rubyforge's rdoc project and I'll get them in asap.
rdoc template patch you might want to hold off on. Jamis sent me one (that I buried of course) and there is another on ruby-talk.
Jun. 25th, 2005 12:39 pm (UTC)
Alright, then. I'll watch for 'em -- feel free to email me patches to test and get comments on, too.

These are all "as time permits" tasks, so they probably won't happen overnight.
Jul. 18th, 2005 11:20 am (UTC)
Currently in Mandriva we enforce /usr/lib/ruby for everything as there are already subdirectories for each arch (the same for perl).

--- mkconfig.rb 2003-08-05 11:27:20.000000000 +0200
+++ mkconfig.rb 2005-03-31 09:18:17.000000000 +0200
@@ -107,7 +107,7 @@
print v_fast, v_others
print <<EOS
CONFIG["ruby_version"] = "$(MAJOR).$(MINOR)"
- CONFIG["rubylibdir"] = "$(libdir)/ruby/$(ruby_version)"
+ CONFIG["rubylibdir"] = "$(prefix)/lib/ruby/$(ruby_version)"
CONFIG["archdir"] = "$(rubylibdir)/$(arch)"
CONFIG["sitelibdir"] = "$(sitedir)/$(ruby_version)"
CONFIG["sitearchdir"] = "$(sitelibdir)/$(sitearch)"
( 6 comments — Leave a comment )