Re: A good location for third party localization files

Scott, thanks for the input.  Comments below...

"Scott Lawrence" <slawrence <at> pingtel.com> wrote in message 
news:1210778900.3196.286.camel <at> scott.skrb.org...
> 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.

Well - the question really is what actually happens to the files after the 
installation.  The third party software we use (and for which I added this 
feature) actually makes a copy of files that match the language identifier 
in domain-config.  So, the files could be considered temporary... 

> I'd say the installation directory should be either
> /usr/lib/sipxecs/locale/≤locale_id>
> or
> /usr/share/sipxecs/locale/≤locale_id>
....
> So I think the distinction is whether or not the files are
> architecture-independent: if so, share, if not, lib.

The problem is that I don't really know and/or control what type of 
localization files will be required by a third party application.  The 
mechanism I implemented is intentionally generic to allow effectively 
anything what might be required by third party applications to be installed. 
Some applications could use files that would better fit into /usr/lib 
(architecture dependent files) while other applications could use files that 
better fit into /usr/share (architecture independent files).  Even worse - 
some applications could use a combination - and I believe that's the case of 
our third party application.

With regard to the locale_id, my expectation was that appropriate 
subdirectories (that distinguish for example locales) would be provided in 
the localization packages.  The actual directory structure would be 
determined by the third party application.  Our installation should 
determine only the base directory for third party localization files.

>> 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).

The sipXconfig process must be able to extract third party directories/files 
from the localization package into the destination directory.  Because 
sipXconfig runs under the sipxchange user, this user must be able to write 
into the destination directory.  I don't think the files (once extracted) 
need to be modified - they could be then considered read only.

> Can you make the distinction between where the files are installed and
> where that state (installed or not) is written?

The state (installed or not) is determined in some way by the actual third 
party application - it was not my intent to dictate how third party 
applications should do that.  For example, the third party application we 
used determines the state by checking the presence of the expected directory 
structure/files.  Having a repository with information about what 
localization files are installed for what languages and where would be nice, 
but third party applications would have to change to make use of such 
information - and that may not be an option in some cases.  The current 
implementation does not track the state at all.

It looks like the candidates for the location of the third_party directory 
are:
1. /var/sipxdata (or /var/sipxecs)
2. /usr/share/sipxecs (or /usr/share/sipx or /usr/share/sipxpbx - as they 
already exist)
3. /usr/lib/sipxecs (currently we have just /usr/lib/sipXpage and 
/usr/lib/sipviewer under /usr/lib)

For whatever reason, I am still leaning towards /var/sipxdata as the best 
choice, but I have my doubts.  Can someone come up with a good reason why to 
go with either one of the three options?

Misha