[rt-devel] mason_data and session_data, cache or lib?

[Jamie Wilkinson]

This one time, at band camp, Stephen Quinney wrote:
>On Thu, Jun 05, 2003 at 07:52:05PM +1000, Jamie Wilkinson wrote:
>> This one time, at band camp, Stephen Quinney wrote:
>> >  prefix:               /usr/share/request-tracker3
>> >  exec_prefix:          /usr
>> 
>> I disagree with this distinction, it doesn't make sense given the usual
>> defaults that packages take.  Since RT is an architecture neutral app, you
>> don't need to make prefix and exec_prefix separate.  In fact I'd be
>> surprised to see any recent Debian package with prefix and exec_prefix not
>> the same.
>
>Not sure what differences this makes to the actually layout of the
>package in the FHS in the case of RT. I'll investigate some more.

Well, none specifically.  But it looks weird :-)

>> >  sysconfdir:           /etc/request-tracker3
>> erk.  So much typing!
>> 
>
>We chose the request-tracker3 name as there is already a package
>called request-tracker (version 2 of RT) and we needed to make the
>distinction clear. We also chose to use the long name in the directory
>names so that it's clear to sysadmins what the directory is for and
>which package it is associated with.

That's what I figured, so I shouldn't complain.

>> >  libdir:               /usr/share/perl5
>> 
>> As John Stoffel pointed out, RT isn't actually a generic perl library, so
>> it's probably better to put the backend of it into /usr/lib/rt
>
>As the RT libraries are architecture independent /usr/share/rt would
>be better than /usr/lib/rt, certainly in Debian we would use
>/usr/share for them.

That's a good point, I'll check it out.

>> >  logfiledir:           /var/log/request-tracker3
>> 
>> I chose /var/log/rt
>
>See my notes about /etc/request-tracker3

Yep.  But since I'm going for OS agnostic FHS with my layout, I think
/var/log/rt and /etc/rt are more appropriate for the upstream source.
 
>I will take a look at those bits again, I find it a bit unclear as to
>what the differences in /var/run, /var/cache and /var/lib really are
>in situations like this.

/var/run seems to be for state files specifically related to the running of
processes.

/var/cache contains dynamically generated data (as seen in mason) that the
admin can nuke at their whim, and it's expected that the program itself will
clean up after itself when it no longer needs the cache.

/var/lib is for state files that need to be preserved between reboots, but
otherwise behaves much the same way as /var/cache -- the main difference
being that of availability.

-- 
jaq at spacepants.org                           http://spacepants.org/jaq.gpg