remove --enable-locations-compression

[oz123]

This tool quite a while to research. I noticed that new installations the clock mate-panel break when trying to add new locations.
It turns out that code could not read /usr/share/libmateweather/Locations.xml.gz. That is because libxml2 disabled built it support for zlib and it will be removed.

Hence, the flag --enable-locations-compression causes broken installation of mate-panel clock applet in the near future:

(clock-applet:26236): MateWeather-CRITICAL **: 16:27:19.137: mateweather_location_ref: assertion 'loc != NULL' failed

The solution for me was for the meanwhile :

cd /usr/share/libmateweather/
sudo gunzip -k Locations.xml.gz

And of course, I need to update the gentoo ebuilds.

[lukefromdc]

Killing that will add something like 80MB to installs. Any chance we can change the compression algorithm instead?

[oz123]

libxml maintainers want to completely remove compression lzma was removed to.
So what we can do is implement reading compressed XML in libmateweater.

[lukefromdc]

Note that with the libxml currently in Debian Sid/Unstable, I just got several builds with compression enabled.

[oz123]

That's good, but that's not the future in releasing newer packages like arch, Gentoo or even Ubuntu.
It's not urgent yet, BUT it needs to be addressed.

[lukefromdc]

That means to support compression going forward, we have to handle it outselves not ask libxml to handle it. Looks like so long as we have --enable-all-translations-in-one-xml we can keep the size of that file to about 17 MB, which hopefully will be good enough. My first builds of libmateweather ten years ago with neither this nor compression yielded a 73+ MB package. Now this is over 100MB. As of now, one file per translation with no compression gives a 114MB directory of roughtly 1.3 MB XML files, while using --enable-all-translations-in-one-xml with nls support to support most languages will give a 17MB file which has to be fully loaded into RAM to use. This of course has to be done whether that file is compressed or not, the 15MB difference should not be too big a problem. Compressing it reduces 17MB to about 2MB. As of now, Debian's libmateweather build both puts all the XMLs in one file and compresses it. A single 2.3MB gzipped file results. For a distro this reduces server bandwidth and for a user this reduces both root file system space usage and update bandwidth. Building separate files with compression gives about 18MB of individual gzipped XML files, with the advantage that only one has to be loaded into RAM (assuming they don't all load by default anyway) and takes about 1.4MB of space there. There is a maximum performance alternative for a user building a package for their own use with only one language Disable-NLS builds give a 2.1MB locations.xml file with --enable-all-translations-in-one-xml enabled but someone using a language other than English trying to stay under 10MB would have buiid with one file per translation, then manually search for and keep the translation they were using and delete the rest. I don't think localepurge can do this for them. Anyway, for now distros can build without compression, they need to be aware of the need to rebuild without compression when they update libxml if we don't fix this. I am OK with dumping this at this point, given that this is simple and if someone wants to code up handling compression ourselves they can. Not sure how much of an issue an extra 15MB is on a root filesystem, but an extra 100MB with individual files might double the size of an entire MATE install at least if only the used locales are being retained, or expand it by roughly 50% if all locales are retained on the system. Gentoo users at least can decide for themselves how to handle this one...