I already submitted a patch for the option #2. If you prefer to go with #1, just let me know.
Misha "Damian Krzeminski" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Misha Vodsedalek wrote: >> I am supposed to fix the problem with the installation of localization >> packages in the main stream >> (http://track.sipfoundry.org/browse/XECS-1557). >> There are at least three possible options - I was wondering if anyone >> would >> have an opinion with regard to which one to select. :-) >> >> The implementation of the support for localization packages (added in >> 3.10) >> included the ability to install 3rd party localization files. As far as >> I >> know, this feature was used only for an external conferencing solution >> which >> is not used in 3.11. Anyway, the directory used for these 3rd party >> files >> in the 3.10 implementation was /etc/sipxpbx/third_party - that was a bad >> choice because all these 3rd party files were included in snapshots. Due >> to >> that, early in 3.11 the directory for 3rd party files was changed to >> /usr/share/sipxecs/third_party (well, to "sysdir.share"/third_party as >> used >> by sipXconfig). With recent changes (in revision 13080), the directory >> "sysdir.share" was changed to /usr/share/java/sipXecs, so now the >> destination is /usr/share/java/sipXecs/third_party. The actual problem >> is >> that the directory /usr/share/java/sipXecs has the owner and group both >> set >> to root. Due to that, sipXconfig (which runs under sipxchange) cannot >> create the subdirectory third_party where there 3rd party files should be >> stored. A check in the installation script if the directory is writable >> fails and due to that, the installation of a localization package fails >> before any files are installed. >> >> Option #1: >> The third party localization file support could be removed from the >> localization context implementation and the installation script (thus >> removing the problem with where to put the 3rd party localization files >> and >> with the permissions, too). >> >> Option #2: >> The destination for 3rd party localization files could be changed back to >> /usr/share/sipxecs. This directory has the correct permissions >> (sipxchange:sipxchange), so the initial check would pass and 3rd party >> files >> could be installed just fine (if any). From looking at sipXconfig, this >> directory (/usr/share/sipxecs) is not used anywhere in the code anymore - >> I'd have to either hard code the directory in the localization context >> implementation or come up with another sysdir member. If this option is >> eventually selected, suggestions would be welcome. >> >> Option #3: >> The destination for 3rd party localization files could be left unchanged >> (/usr/share/java/sipXecs/third_party), but the user and group of the >> directory /usr/share/java/sipXecs would be changed to >> sipxchange:sipxchange. >> This directory is actually used by six RPMs (subdirectories are created >> in >> this directory and files stored in them). The directory itself is not >> specified in any of these RPMs, so default attributes are used and that's >> why it gets root:root. So, the solution would be adding the directory >> with >> appropriate attributes to the 6 RPM spec files. >> >> Personally, I am tempted to suggest #1 as the option to choose, but I >> don't >> know if it's safe to assume that nobody started to use this functionality >> since it was documented as few months back. My second choice would be >> the >> option #2. >> >> Misha >> >> >> > > Looks like it's been couple of days and no-one complained yet... > So I would suggest you go with #1 and if someone needs it they can re-add > it in a way described in #2 > D. > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
