On 30/12/2019 16:39, Adriano dos Santos Fernandes wrote:
We need to consistently handle the situation, in regarding to multiple OS and different deploy of ICU, so CORE-6215 seems not the way to go IMO.
In Linux, Firebird is far more likely to use the system ICU distribution, which will be kept up-to-date externally. And otherwise the ICU tools are readily available from a package manager.
The same doesn't apply to Windows. In that regard, Windows is an oddity, so having specific tools included on Windows, but not on other platforms, should be a possibility.
It's easy to make a standard subdirectory inside Firebird tree to put the *.res files and automatically call setenv in the engine start before load ICU.
>
However it will not work in embedded if the application previously loaded ICU (the same DLLs used in Firebird). Maybe this is not important and in the worst case application developer may explicitly call setenv at appropriate moment.
There is also u_setDataDirectory() (see http://userguide.icu-project.org/icudata), but I don't see how that meshes with our current usage.
We also need a good way to release: 1) every time zone table update at our website 2) release the latest table with every Firebird release This could be done downloading the appropriate ICU tzdata *.res files and commiting as a zip to our github (in FirebirdSQL/firebird, in every supported branches). Then build/package scripts would put that files in the right place of distribution kits.
Is putting such external binary dependencies in the repository is the right course of action? Why not download the latest directly from the ICU site (https://github.com/unicode-org/icu-data/tree/master/tzdata/icunew) when you need it? Though that has the downside of decreasing the repeatability of a build.
I'm also not sure if it makes sense to include the .res files in the build: in that case you can (and I think should) use the updated ICU data file or expect the system ICU to be up-to-date.
It also doesn't really address the fact that over the past few years, there have been more frequent tzdata updates than there have been Firebird releases.
Our website could link to the latest zip (master branch) of our github's tzdata. Opinions?
We can also point people to the ICU site. That way, you also prevent the busywork of having to track and include that ICU data in our repository for each tzdata release. Which is a chore that I easily see being forgotten.
Alternatively, we should be prepared to release a new Firebird version on short notice if a new tzdata release has been made. People who (have to) remain on older versions then have the fallback option to do update the tzdata manually.
Mark -- Mark Rotteveel Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
