Apache OpenOffice (AOO) Bugzilla – Issue 34269
instsetoo_native: missing files for languages (fallback to en-US)?
Last modified: 2004-11-26 16:44:23 UTC
Hi, I'd like to build SRC680_m47 native package for GNU/Linux (I'm using SuSE Linux 9.0 as build machine). dmake finished without errors (after some manual tweaking ;-) and I did this: cd instsetoo_native build cd util dmake openoffice English RPM packages are OK, but it failed for language cs, because; ... languages cs ... ... analyzing files ... ERROR: The following files could not be found: ERROR: File not found: palettes_cs.zip ... cleaning the output tree ... *************************************************************** ERROR: Missing files in function: remove_Files_Without_Sourcedirectory Saved logfile: /home/oo/BuildDir/ooo_SRC680_m54_src/instsetoo_native/unxlngi4.pro/OpenOffice/logging/cs/log_SRC680__cs.log *************************************************************** Thu Sep 16 18:57:56 2004 (00:01 min.) dmake: Error code 255, while making 'openoffice_cs' '---* tg_merge.mk *---' And yes, palettes_cs.zip doesn't exist, because: pavel@linux:~/.ooo/ooo_SRC680_m54_src/extras/source/palettes> ls -al lang/cs ls: lang/cs: No such file or directory After manually copying en-US to cs in lang directory and re-dmake and deliver, it was finished. We would like to reduce the need of patching/copying for creating new language. Is it possible to fallback to en-US version every time the proper language version is not available? palettes_en-US.zip does exist, so why not use it? It is much better than barfing.
Hi Pavel, using native installer it is very difficult (or impossible) to use the fallback mechanism to en-US. The problem is, that every file in every package has to be unique. At least we need a different file name or a different installation directory. With the introduction of language packs, it has to be possible, to install an english language pack (which will be the core packages) and a czech language pack together on one system. If there are english files in the czech language pack, you will get a confict and the installation of the czech language pack will fail. On Windows you get errors, when validating the msi database, because the same file is installed by different components. No, I think we cannot support the fallback mechanism anymore. Renaming the package palettes_en-US.zip to palettes_cs.zip is only a good solution, if you want to install only one language. Correct would be to check, if there are language dependent directories in the zip file (and to adapt the directory names) and to look for language dependent file names. A simple fallback is not sufficient.
Setting to wontfix
Well, if it is guaranteed that there is never a language dependent file name and never a language dependent directory name included in a zip file, then it is acceptable to introduce a fallback mechanism. The language dependent directories always have to be defined in the scp project. -> reopen
is: to whom should I reassign? ause?
No, not Ause, this is my task. Probably it will contain also some changes in the scp project. All files have to be marked, that can be defaulted for OpenOffice.org. For StarOffice all files have to be available. I will have to include a mechanism, that files with a special scp flag are allowed to be defaulted to the english version if OpenOffice.org is packed.
set target
*** Issue 34584 has been marked as a duplicate of this issue. ***
Hm, this is Prio 2 like task #i34584
Setting me on CC as this one seems to be the successor of 34462 and 34584. We really need either this fallback mechnism or some dummy files in 'extras'.
Setting to Prio 1 for fixing on master.
If the environment variable DEFAULT_TO_ENGLISH_FOR_PACKING is set, english files are taken as default for all multilingual files. This environment variable must not be set for product releases! This mechanism does not work for missing License files, because there is a special handling for License files!
I think the reverse approach would be better, ie setting DO_NOT_DEFAULT_TO_ENGLISH_FOR_PACKING to something will work as before. Why? - this is another thing that people must do before they start building - we have to set it somewhere What do you thing?
Verified. DO_NOT_DEFAULT_TO_ENGLISH_FOR_PACKING works perfectly. The default value should still be changed, IMO. But this is another case. Closing.