Updating quazip breaks OpenBoard

[Larson40]

The most recent update of quazip breaks some dependants. OpenBoard will not function once quazip-1.0-1x86_64 is installed. Removing, and attempting to install OpenBoard after update results in errors stating that quazip.h is not found.

Reverting quazip back to quazip-0.9.1-1-x86_64 restores OpenBoard functionality, and allows you to install OpenBoard without any errors.

[stachenov]

I don't think I can help here. I don't even know what OpenBoard is, how it is related to QuaZip and how they are installed. It is obviously a problem with installation/packaging. QuaZip 1.0 uses CMake as the main and only build system, and whatever dependents are using CMake properly, they will transition to 1.0 with no problems. However, 1.0 is not a replacement for 0.x. It uses different installation paths and/or file names, so that 0.x and 1.0 can be installed simultaneously on a single system. Whatever OpenBoard is, unless there is a new version build explicitly with QuaZip 1.0, it should continue using 0.9.x even if 1.0 is installed.

The best thing I can do is to provide some kind of migration guide with the next release. But I thought that compatibility between major releases is not expected by default by any users.

[Larson40]

OpenBoard is a digital whiteboard program used by teachers. I am not a developer, but from my troubleshooting last night, I believe that when the newest version of quazip is installed, it changes the directory of the older version of quazip. By changing the directory, the OpenBoard installation no longer is able to find the quazip files. OpenBoard is using qmake for its installations.

I am not sure whether that means that OpenBoard has improper syntax, or if quazip is not supposed to change directories.

[stachenov]

QuaZip doesn't really change directories. QuaZip 1.0 is supposed to coexist with QuaZip 0.x, not replace it, so it obviously installs into a different directory. So whatever software is using QuaZip 0.9 should continue to do so even if QuaZip 1.0 is installed. If some installation process removes QuaZip 0.9 as a part of QuaZip 1.0 installation, that installation process is at fault here. OpenBoard shouldn't even be aware of QuaZip 1.0 installation, it should continue to use 0.9 until OpenBoard developers decide to switch to QuaZip 1.0.

[stachenov]

Thinking about it for a while, I find it very confusing: “...update results in errors stating that quazip.h is not found...”, “...OpenBoard is using qmake for its installations...”. *.h files and qmake are only used during compilation, not installation.

If this is about installing OpenBoard from source (that is, not from some prebuilt binary package), then there may be a way to make it work with 1.0. qmake just needs additional paths, something like

qmake ... INCLUDEPATH+=/usr/include/QuaZip-Qt5-1.0/quazip

(Or whatever the path to QuaZip includes is.)

There maybe a problem, however, at the linking stage, if it has -lquazip hardcoded somewhere in *.pro files. Because QuaZip 1.0 uses naming scheme like libquazip1-qt5, not just quazip. This, again, can be sort of “fixed” by creating a symlink libquazip.so pointing to libquazip1-qt5.so.1.0.0, or whatever the name is. Or by patching OpenBoard *.pro files to link to -lquazip1-qt5 instead.

This all is, of course, very hacky, but so is installing anything from source.

Migration to CMake was done exactly to avoid this kind of neverending qmake problems. Qt itself is switching to CMake since Qt 6.0.

[Larson40]

I have spent some time looking at the OpenBoard code. Again I'm not a developer, so I have a very limited knowledge of what things are supposed to look like. There are many places that quazip is used. Unless I missed something, I didn't see any hard coded quazip directory.

I am using Arch linux, and the yay package manager. I tried looking at the PKGBUILD files on the AUR for quazip, but didn't see anything that I could determine would cause it to move the old quazip files, but It does point to new quazip files being located at /usr/include/QuaZip-Qt5-1.0/quazip/.

I believe that the old quzip files were located at /usr/include/quazip5.

That's just about all I really know about this type of programing, but thank you for working with me on this.

[droidmonkey]

@stachenov unfortunately the reality is that no one knows that 1.0 is intended to allow coinstall with 0.x versions. I am getting hounded to support 1.0 installs for KeePassXC and I am pretty sure it is not ABI compatible with 0.x. There is not enough documentation for me to make that decision besides testing. One concern I have is to make sure downstream distros (Debian, Ubuntu, Fedora, etc) need to maintain dual availability of 0.x and 1.0 for the foreseeable future. If that is not happening then we have a major problem.

[stachenov]

Yes, that is how I see it too. I was against these changes at first, but there was really no other way, as 0.x supported both qmake and CMake, and those evolved independently, as I didn't know CMake at all back then, so I maintained qmake and blindly accepted every PR for CMake. That inevitably led to terrible mess when nobody understood anymore, whether it's #include <quazip.h> or #include <quazip/quazip.h>, whether it's -lquazip or -lquazip0 or -lquazip1, or -lquazip5... Add awful pre-modern CMake style, and the mess becomes even more terrible. The only way out was to change everything to a consistent scheme. This lead to ditching qmake, which I didn't want to do either, but it turned to be the only way to maintain guaranteed consistency.

Perhaps it was my great fault that I didn't provide any 0.x->1.0 maintainer's/packager's/migration guide. I hope it's not too late to release 1.1 with something like that, but then again I have no way to guarantee that package maintainers will actually read it.

As far as ABI compatibility goes, I believe it is compatible. At least I don't remember changing anything that might break it. I haven't paid much attention to it, though, since the binary name is different, so nobody is supposed to accidentally start using 1.0 without explicitly rebuilding for it.

[droidmonkey]

Thanks for the response, agree it is terribly hard to herd all the distro cats out there. We will migrate to 1.0, but supporting both 0.x and 1.0 for a period of time may be challenging if its not abi compatible. The joys of programming!

[stachenov]

The problem is not ABI compatibility here. QuaZip 1.0 has different include paths and different binary name. On a single system, QuaZip 0.9 may (or may not because of the mess I described above) have these:

/usr/include/quazip5/*.h
/usr/lib64/libquazip5.so.1.0.0

and QuaZip 1.0 will have (unless the maintainer changes it explicitly):

/usr/include/QuaZip-Qt5-1.0/quazip/*.h
/usr/lib64/libquazip1-qt5.so.1.0.0

So whatever software linked to libquazip5.so.1.0.0, it will not even see the “updated“ binary. This was intended. Indeed, there is no other way because of the same mess: QuaZip 1.0 can't be guaranteed to use the same binary name as 0.9 because 0.9 used different names depending on whether it was built with qmake or CMake, and possibly other factors as well.

Since it was impossible to maintain both compatibility with 0.x and naming consistency, the latter was chosen and the file names and paths were chosen in such a way to avoid possible conflicts with 0.x and possible future major versions (and different major versions of Qt too).

So the intended way of supporting both was this: just install them both and let 0.x users use 0.x and let those who consciously moved to 1.0 use 1.0. What I did not foresee, however, is that some maintainers will simply regard 1.0 as a replacement upgrade for 0.x...

[stachenov]

There's the first version of migration guide. Comments and corrections are welcome.

[stachenov]

Filed an Arch Linux bug report 68196.

[stachenov]

...which was closed almost instantly. It turns out Arch Linux is not very developer-friendly. “Every official package is ported to use the new paths” is the reason for closing, which assumes that anyone who's willing to build a 3rd party unofficial package is pretty much screwed.

Well, what can I say? Just install QuaZip 0.x from sources locally. It's certainly a messy way of doing things, but works in a pinch.

[antonio-rojas]

...which was closed almost instantly. It turns out Arch Linux is not very developer-friendly. “Every official package is ported to use the new paths” is the reason for closing, which assumes that anyone who's willing to build a 3rd party unofficial package is pretty much screwed.

As it's the case for every single backwards-incompatible library update. We don't keep old versions of libraries in the official repos unless there are official packages that need them and can't be ported, I don't see why it should be different for quazip.

[stachenov]

That's OK with me. I understand that there is no single solution that makes everyone happy and is available for free, on top of that. Besides, I'm not even an end user, so it's like I'm affected in any way except that people come to me when they have any problems with my library. But that's expected.

[iyanmv]

I added the legacy 0.x version to AUR. People can use that instead of the quazip 1.x from the official repos to specific cases like OpenBoard.

[Scimmia22]

OpenBoard already had to be patched in the AUR for the header path. The change here just means that the downstream patch had to change.

Seriously, multiple upstream and downstream bug reports, suggestions of weird symlinks, and extra packages just to avoid changing a downstream patch?

[bartoszek]

@stachenov Sorry for getting late to the party, I've updated quazip.patch for AUR/openboard{-git} to reflect migration changes.

Builds fine on gcloud although can't test it now, so @Larson40, @Scimmia22 perhaps you could gave it a shot.

If it wont work, I'll fallback to @iyanmv legacy quazip package, otherwise it can be safely removed.

btw. Quickest way to reach me is by posting issue/pr on GitHub, each package I'm maintaining has it's mirror on GitHub - https://github.com/bartoszek/AUR-openboard

[iyanmv]

Works fine for me 👍

[Larson40]

@bartoszek When attempting to build openboard-git, I receive the following error.

[stachenov]

@Scimmia22

OpenBoard already had to be patched in the AUR for the header path. The change here just means that the downstream patch had to change.

Seriously, multiple upstream and downstream bug reports, suggestions of weird symlinks, and extra packages just to avoid changing a downstream patch?

Just to clarify: I'm not familiar with Arch Linux, so I assumed the OP tried to build OpenBoard from source using QuaZip installed from an Arch Linux package. I had no idea about neither AUR nor the existing patch.

Now I understand that of course it makes perfect sense to just update the downstream patch.

[bartoszek]

@Larson40 clear build cache, you have old version of quazip.patch that nedd redownload.

[bartoszek]

@Larson40 @iyanmv I've pushed also develop and git-develop version to test OpenBoard:v1.6.0alpha . All builds fine as for now, didn't test them although.

Current packages state:

• openboard
• openboard-git
• openboard-develop
• openboard-develop-git