Re: A good location for third party localization files
Scott Lawrence <slawrence <at> pingtel.com>
2008-05-14 15:28:20 GMT
On Wed, 2008-05-14 at 16:34 +0200, Misha Vodsedalek wrote:
> Even though the documentation for localization packages on the sipX Wiki
> does not mention it yet (quite intentionally), it is actually possible to
> include localization files for third party applications in localization
> packages. My initial implementation (submitted in 3.9) places these third
> party files into /etc/sipxpbx/third_party. When I found out that using this
> location is not optimal, it was too late to change it for the 3.9/3.10
> stream.
We have tried (not always successfully) to use the Filesystem Hierarchy
Standard <http://www.pathname.com/fhs/pub/fhs-2.3.html> as a guide to
this sort of thing.
> The main reason why /etc/sipxpbx should not be used for various "junk" such
> as third party files is simple - the entire directory structure gets
> included in snapshots and thus should contain only configuration files! My
> personal guess is that not that many designers actually know this, because
> you can find variety of files in the directory structure. 
>
> Sorry for the long introduction - now to the point. I don't want to make
> the same mistake twice, so I am looking for some feedback with regard to the
> right location for third party localization files. I am considering moving
> the third party directory to
> /var/sipxdata/third_party
> Would that be okay or are there any gotchas related to the /var/sipxdata
> directory structure?
The FHS says:
/var contains variable data files. This includes spool
directories and files, administrative and logging data, and
transient and temporary files.
that doesn't fit.
> Would there be a better (or more appropriate) location
> for such files?
I'd say the installation directory should be either
/usr/lib/sipxecs/locale/≤locale_id>
or
/usr/share/sipxecs/locale/≤locale_id>
The FHS says:
/usr/lib includes object files, libraries, and internal binaries
that are not intended to be executed directly by users or shell
scripts. [22]
Applications may use a single subdirectory under /usr/lib. If an
application uses a subdirectory, all architecture-dependent data
exclusively used by the application must be placed within that
subdirectory. [23]
and
The /usr/share hierarchy is for all read-only architecture
independent data files. [30]
This hierarchy is intended to be shareable among all
architecture platforms of a given OS; thus, for example, a site
with i386, Alpha, and PPC platforms might maintain a
single /usr/share directory that is centrally-mounted. Note,
however, that /usr/share is generally not intended to be shared
by different OSes or by different releases of the same OS.
Any program or package which contains or requires data that
doesn't need to be modified should store that data in /usr/share
(or /usr/local/share, if installed locally). It is recommended
that a subdirectory be used in /usr/share for this purpose.
So I think the distinction is whether or not the files are
architecture-independent: if so, share, if not, lib.
> Please note that the requirement is that sipXconfig must be able to write
> into the base directory in which the directory third_party will be created
> (it's sipXconfig that actually installs the localization files). So, the
> directory should be owned by sipxchange.
What needs to be written? That does sound like /var/sipxdata (which
really should have been /var/sipxecs, I guess, but close enough).
Can you make the distinction between where the files are installed and
where that state (installed or not) is written?
--
--
Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:slawrence <at> pingtel.com
sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs
CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/
http://www.pingtel.com/
RSS Feed