Re: Where does data provided by ruby packages go?
On Sun, 17 Jan 2010 16:32:29 +0100
Jérémy Lal <jerry@edagames.com> wrote:
> On 17/01/2010 16:12, Ben Armstrong wrote:
> you could have a look at redmine package (a RoR app),
> which deals with defining proper paths for these cases :
> static data, www-dir in /usr/share/redmine(/public)
> cached data in /var/cache/redmine
> uploaded data in /var/lib/redmine(/files)
> configuration yml in /etc/redmine
> logs in /var/log/redmine
That's a rather complex example, and ultimately it dodges the issue I
want to solve by falling back on the all-in-one-dir approach for rails
itself (under /usr/share/redmine, with symlinks in vendor to point at
the bits provided by other Debian packages) instead of the more
conventional, simple ruby app that provides:
lib that under Debian is installed in /usr/lib/ruby/1.8/appname
bin that under Debian is installed in /usr/bin/binname
...
data that under Debian is installed in ?
I *think* the right answer to this question is
simply /usr/share/appname (which is inconsistent with snmp's
implementation). So what's an upstream developer to do in the middle
of this chaos? I want my software to work everywhere. I don't want to
assume gems, and I don't want each packager to have to hardwire any
paths. Is there no convention that helps, here? I thought I was on
the right path when I found rbconfig. I thought all I would need to do
is:
1. test for all-in-one-dir:
File.directory?(File.join(File.dirname('__FILE__','..','..','data')))
2. test for rbconfig:
packagename='live-workbench'
File.directory?(File.join(Config::CONFIG["datadir"],packagename)
But does that cover all of the bases? What if ruby itself is
installed in /usr and live-workbench is installed in /usr/local? How,
short of a hardwired list of possible locations, is an application
written to be run everywhere, to discover where the data has been put?
Then I discovered setup.rb. Surely setup.rb could write some config
for the app when it is installed to *say* where the data was put. Yet
I find no precedent for that, either, in the code I have surveyed so
far. And I was hoping not to "reinvent the wheel" by coming up with my
own solution here, but simply to use what everyone else uses.
Frustrating. There must be a better way than ad-hoc solutions to this
problem.
Ben
Reply to: