Consider upgrading to QEverCloud 3.0 and using it as a shared library / dependency

[d1vanov]

Hi!

I've just recently released the 3.0 version of QEverCloud library which NixNote2 uses. There were no actual changes in the functionality (so the upgrade is not urgent), however, the infrastructure was set up to enable the building and shipping of QEverCloud as a shared library. It would be nice for NixNote2 to consider having QEverCloud as an external dependency. Although it might complicate the shipping of NixNote2 itself, it is actually in accordance with the rules of almost all major distros to depend on external shared libraries rather than shipping their compiled code along with the applications.

I've actually made some effort to provide the packaging infrastructure for QEverCloud - right now source & binary packages for Debian Jessie, Linux Mint 17 (should be binary compatible with Ubuntu 14.04) and Fedora 24 are available. I haven't made any attempts to get QEverCloud put into the official repositories of any distros yet but I intend to try.

[baumgarr]

Until it is in the standard repositories of multiple distros then I can't make it a dependency. It would make distributing it a pain & I'd get multiple tickets about missing dependencies.

[hosiet]

QEverCloud should work as shared library (at least in Debian), sorry I didn't notice that. One Debian Developer reminded me while I was working on the Debian package for nixnote2.

I will start the investigation on packaging QEverCloud into Debian, and hope that nixnote2 could provide with a way to use external shard library in configure-time option.

[d1vanov]

@hosiet, thank you very much for your efforts!

Just in case, I already have some version of QEverCloud deb package, you can find latest binary + source packages for Debian Jessie here. The sources of the package itself are hosted here. These are for stable branch of Debian, not for experimental one (where AFAIK all the new Debian packages should first appear) but I hope the necessary adjustments for experimental branch should be small.

Please contact me should you need any assistance with it from my side.

[baumgarr]

Don't forget to add it to Suse and Arch and Fedora and Gentoo and every other distribution.

Until it is in the majority of distros it just adds to the complexity with no real benefit. I think I even read from the author of QEverCoud that he isn't working on any new releases.

[d1vanov]

The original author truly does not work on the new releases. However, more than a year ago I took the project over and I am going to maintain and develop it further.

I understand your point about the complexity but, as I mentioned in the first post of this issue, the vast majority of distributions have rules that apps should not include their dependencies into themselves. I have no idea whether you even care about NixNote2 being accepted into the official repositories of major Linux distros but if you do, you don't really have the option of not using the external dependency.

And one more slightly off-topic thing: you might be interested to take a look at AppImage project as it strives to provide a way to package Linux apps in a way somewhat similar to Mac apps - in bundles including all the dependencies, exactly with the purpose to eliminate the problems with missing dependencies.

[baumgarr]

If what is what is keeping NN out of any distros then I'll just fork QEverCloud and consider it part of NN.

I'm not including any binary dependencies. It was designed and distributed as a C++ library to be included in other packages.

In a perfect world I would agree, but with the complexity of things I really don't have a choice.

I do wish you the best of luck. If it is picked up by enough distros I'll use it in a few years.

[d1vanov]

Well, you seem to already consider QEverCloud a part of NN :) However, your consideration might not be agreed with by the distribution maintainers - that's sort of what has already happened in the case of Debian.

Anyway, I won't argue further, I created this whole issue just FYI. Thanks for wishing me luck, I wish you good luck as well! 👍

[hosiet]

If we need to migrate to QEverCloud 3.0+, the source code needs some modification due to header file change as described here. This will need a little work on the source code and the build system, but won't be difficult.

It is also possible to select to build with static library or the shared library, but unfortunately I am not really familiar with CMake. I am much more familiar with Autotools(autoconf/automake), though.

[probonopd]

And one more slightly off-topic thing: you might be interested to take a look at AppImage project as it strives to provide a way to package Linux apps in a way somewhat similar to Mac apps - in bundles including all the dependencies, exactly with the purpose to eliminate the problems with missing dependencies.

Let me know if you are interested in providing an AppImage, I can help writing a recipe for it.

[hosiet]

FYI I have already put the QEverCloud 3.x library into Debian official repository (https://tracker.debian.org/pkg/qevercloud). This library will be available in Debian Stretch (Debian 9), Ubuntu 17.04 and later Debian-based derivatives.

Please do consider migrating to the shared library, or at least provide with a compile-time option.

[probonopd]

@hosiet do you see a possibility to do a backport for oldstable or trusty or earlier? Then it would be trivial to make an AppImage out of it as well.

[hosiet]

@probonopd I didn't try it but building the shared library should be possible. I am not familiar with the principle of AppImage: does AppImage package need deb package? If not, You may just try to build from source. If yes, we can try backporting later.

[probonopd]

There are different ways to generate an AppImage of your application, among them:

• Convert existing binary packages. This option might be the easiest if you already have up-to-date packages in place, ideally a ppa for trusty or earlier or a debian repository for oldstable. In this case, you can write a small .yml file and in many cases are done with the package to AppImage conversion. See examples OR
• Bundle your Travis CI builds as AppImages. This option might be the easiest if you already have continuous builds on Travis CI in place. In this case, you can write a small scriptfile and in many cases are done with the AppImage generation. See examples OR
• Manually create an AppDir and turn it into an AppImage.

Converting existing binary packages is usually the easiest if you already have existing debs.

More information is on https://github.com/probonopd/AppImageKit/wiki/Creating-AppImages.

No matter how you generate your AppImage, the ingredients used in your AppImage should not be built on a more recent base system than the oldest base system your AppImage is intended to run on. Some core libaries, such as glibc, tend to break compatibility with older base systems quite frequently, which means that binaries will run on newer, but not on older base systems than the one the binaries were compiled on.

If you run into errors like this

failed to initialize: /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.11' not found

then the binary is compiled on a newer system than the one you are trying to run it on. You should use a binary that has been compiled on an older system.

[hosiet]

@probonopd Thanks for your explanation, but I am not interested in backporting a library to oldstable solely, especially when oldstable has already reached EOL(end-of-life) state. I am not a Ubuntu developer so there is little chance that I could push it into trusty-backports. I may consider it if any of the useful software depends on it, e.g., nixnote2.

[d1vanov]

@probonopd, what would be the purpose of making an AppImage of a library which QEverCloud is? I thought AppImage is intended to distribute applications?

[probonopd]

@d1vanov sorry if this was unclear - I was referring to NixNote 2 which uses QEverCloud.

[d1vanov]

@probonopd, if so, I think there's a much easier way to make an AppImage for NixNote 2 - currently its source tree includes the entire source of QEverCloud and these sources are built right into the application. While such practice is not acceptable in most Linux distributions, I would guess it should be perfectly fine for the AppImage. In that case no Debian package for QEverCloud is of any interest for the AppImage of NixNote 2.