I am upstream for a ruby app I am in the process of designing/writing. The app is intended as a piece of Debian infrastructure, so writing it to be easily packaged is an important concern. I explained a little bit about what I'm doing here (probably not, now that I think of it, the right list for this, which may explain why it got no responses):
http://lists.alioth.debian.org/pipermail/pkg-ruby-extras-maintainers/2010-January/004436.html Today's problem is this: the application will provide static data in a 'data' directory. On a Debian system, I believe it should be installed somewhere under /usr, but I am not sure where. I asked #ruby @ irc.freenode.net and mostly got blank stares. They said that the normal approach here is to use rubygems, and suggested I look at other gems to find out what they do. Well, my problem with that advice is that of all of the gems I have ever installed, only snmp both provides data and is in Debian (the libsnmp-ruby1.8 package), and I don't trust that as a good example to follow. In snmp/mib.rb, the upstream package looks in two locations, one relative to the code (for the all-in-one-dir approach, e.g. either a gem, or running the code in-place, checked out from revision control) and the other relative to rbconfig's Config::CONFIG["datadir"], which on a Debian system is /usr/share. However, for the latter, it expects the data to be in ./ruby/snmp/mibs, and since there is no precedent in Debian for putting data under /usr/share/ruby, the maintainer has replaced the all-in-one-dir location with a hard-wired /usr/share/doc/libsnmp-ruby1.8/yaml/. This also seems wrong to me, as the files provided are not really documentation. So where do I go from here? There should be some standard way for a package to either work in an all-in-one-dir arrangement *or* with data stored relative to Config::CONFIG["datadir"] but I can't find a single example of code that does this in a way that would mesh well with Debian. Ben -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
