Old versions get deprecated and newer versions disappear too fast

[leorolla]

Quick version release and imcompatibility between different versions is making it harder for me to use IPE with my collaborators.

New versions appear on https://ipe.otfried.org/ and the previous versions disappear almost immediately, and I spend more time now trying to get IPE to work than working on my figures. And unfortunately I may be unable to get my collaborators to install the same version.

I had installed 7.2.24 on Ubuntu 20.04 some time ago, which I had downloaded from IPE webpage. Now I installed IPE on another machinge running Ubuntu 20.04. It turns out, Ubuntu 20.04 will install 7.2.13 from its repositories, which it will not open files saved in 7.2.24.

I searched a lot trying to find for the same .deb file I had previously found at https://ipe.otfried.org/, thinking it would be a pice of cake as it had been in the past, but it was not longer available. I did find a deb file for 7.2.24 in other places, including Ubuntu 22.04, but it would not install in Ubuntu 20.04 (the source code would not compile either). Finally, I downloaded the source of 7.2.26 for Ubuntu 20.04 from an old mirror https://provo-mirror.opensuse.org/repositories/home%3A/otfried13/ and managed to compile it from source. The page https://download.opensuse.org/repositories/home:/otfried13/ no longer has a folder for Ubuntu 20.04. I believe I had seen one just today, either at this website or a very similar one.

And after all that, I'm not sure I can edit the file with my collaborators who use Windows. As of today (10th May 2023), they can only download 7.2.27 from https://ipe.otfried.org/, whereas I am using 7.2.26.

I suggest keeping some "Long Term Support" versions available, for people who need stability in their workflow and compatibility with their team of collaborators.

It would also be great if binaries for Ubuntu 20.04 were still distributed.

[otfried]

Incompatibility between different versions

The current Ipe file format is the one of Ipe 7.2.18. That means that all Ipe versions from 7.2.18 until 7.2.27 are 100% compatible, and that the Ipe file format has been stable now for three years.

The previous versions disappear almost immediately

I'm sorry you were unable to find older releases, but, you know, you could simply have asked me.

Last weekend I have finally published the Ipe sources on github, which is something several Ipe users have been asking me to do for years. It was necessary to switch the repository for that, so older releases are now at https://github.com/otfried/old-ipe-releases/releases. I have added a link to the Ipe webpage.

I strongly recommend against downloading sources from random places on the internet if you care at all about the security of your system.

It would also be great if binaries for Ubuntu 20.04 were still distributed

Four weeks ago I asked on the ipe-discussion mailing list if anybody saw a problem with Ipe migrating to use Qt6. The only feedback I got was in favor of the migration.

Since Qt6 is not available for Ubuntu 20.04, that means providing packages for Ubuntu 20.04 is no longer possible.

The way that https://build.opensuse.org works means that once I build a new version, the repositories for the older versions disappear. Ipe is a one-man project, I don't have a release management team that figures out the right dependencies for each platform and builds the most recent Ipe version that can be built for each. If the Linux binaries that I build are not useful in the current form, then I will stop building them.

If you feel that binaries for Ubuntu 20.04 should be distributed, please take over that responsibility:

• https://build.opensuse.org is free
• The spec file needed to compile Ipe 7.2.6 is publicly available at https://github.com/otfried/ipe-tools/tree/master/obs, you would need commit d41d4bb6a4eda38448eab31c16e92212e55d6f1b for 7.2.26.
• I'd be happy to link to your repository from the homepage then.

[leorolla]

Thank you for your quick response and clarifying the versioning cycle.

Also, thank you very much for developing and maintaining this project!

I understand that keeping track of which version can be built in each platform is not worth the trouble. Perhaps a compromise solution would be to take a snapshot of the binary packages linked from https://ipe.otfried.org/ before a major upgrade.
A "major upgrade" would include: one that changes file format (so that it will produce files that might not work with previous versions); migration to Qt6 leaving behind some stable Linux distros; etc.

These "stable" binaries could be hosted on Github instead of Opensuse, like Windows and Mac binaries currently are.

Fedora 36, Debian 10, Debian 11 and Ubuntu 20.04 are broadly used platforms that are still supported by their developers, and they worked fine with IPE 7.2.26.

The opensuse mirror
https://provo-mirror.opensuse.org/repositories/home:/otfried13/
still has binaries for all these 4 distributions

I believe this would benefit many end users.

Thanks!

[MarkCotch]

I am having a similar issue. I support users that are running RHEL 8 & 9 (which are current release supported by Red Hat). It seems that your application is advancing the library minimum compatibility faster then the Red Hat LTS life-cycle rendering your applications library incompatible with the latest EL commercial platforms or derivatives (eg. Rocky 8/9, Oracle OS 8/9, etc). In its current state your software is useless for our research purposes.

I can understand wanting to keep with the latest cutting edge libraries, however stability and usability are critical in the area's of research that I support. We need a reliable product that will work across the life-cycle of our commercially supported environment. Constant changes tends to be a problem especially in research where the ability to reproduce results is essential.

Do you have a packaged RPM version(s) that are compatible with RHEL 8 & 9?

[otfried]

Are you talking about the switch from Qt5 to Qt6?

This had nothing to do with "wanting to keep with the latest cutting edge libraries". Ipe switched

(1) on request of Ipe users, who needed Qt6 features and bug fixes that are not available for Qt5;
(2) after consulting the Ipe discussion mailing list and asking for user concerns (there were none);
(3) in view of the fact that the open-source version of Qt5 is now unsupported and receives only some fixes from the KDE project (https://en.wikipedia.org/wiki/Qt_version_history).

If you really want to use the latest version of Ipe on RHEL 8 or 9, you can install Qt6; either compiling it yourself or from a 3rd-party repository.

Otherwise you'll have to stick with the latest Ipe version that uses Qt5, which is Ipe 7.2.26, available here: https://github.com/otfried/old-ipe-releases/releases

[MarkCotch]

I had a painful source build of V7.2.24. Many elements (i.e. libspiro) had to be installed from source as well to get a build that could compile for RHEL 8.

[otfried]

I've never used RHEL, so I can't really help you here. Isn't RHEL 8 based on Fedora 28, can't you simply use the Fedora package for libspiro?

In any case, I routinely build Ipe binaries for Windows and MacOS, and in both cases I need to compile all dependencies from source, so I know it's not hard.

I still do not know what you are actually complaining about. Ipe doesn't use anything "cutting edge" - on the contrary, I've always been quite conservative with adding and updating dependencies, even if that annoyed Ipe users. Arch Linux, for instance, updates libraries to the newest cutting edge version all the time.

[MarkCotch]

Firstly, I'm a system's administrator, not a software developer. Diagnosing Makefiles and code isn't the best use of my time. When I delve into the build requirements of your RPM there are requirements inconsistent with what appears the be the code's requirements.

For example the RPM has a dependency for Gnu Standard C++ Library (GLIBCXX) of V3.4.30
[root@el8Test ~]# rpm -qR ipe-7.2.27-171.1.x86_64.rpm | egrep 'GLIBCXX' | tail -1
libstdc++.so.6(GLIBCXX_3.4.30)(64bit)

Whereas RHEL 8 latest reported version is 3.4.25. This causes the RPM to fail install for lack of sufficient core element.
[root@el8Test ~]# strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX_3 | tail -1
GLIBCXX_3.4.25

This would make sense if your code specifically uses new features added in V3.4.30, but that does not appear to be the case. I would guess the "rpmbuild" on the build system is set to narrow parameters on the build system. I guess what I'm asking is that your packaged software not be as restrictive in library version requirements without specific necessity.

This time, as a one-off, the installation was eventually completed, but this process cannot scale.

[otfried]

I'm a mathematician. I know next to nothing about packaging software for Linux, and do not even have access to a Linux system using RPM packages.

Apparently you downloaded an RPM package built for Fedora 38. Why would you expect that to work on RHEL 8, which is based on Fedora 28?

For what it is worth, all RPM packages available on ipe.otfried.org are built using the openSuse build service. All I do is upload the sources and a small spec file. You can find the spec file for the current RPM here:

https://build.opensuse.org/package/view_file/home:otfried13/IpeRPM/ipe.spec?expand=1

You'll see that it doesn't specify any library versions - this is all rpmbuild's doing.

I'd be happy to add a target suitable for you, but the build service doesn't seem to offer either RHEL 8 or Fedora 28.

You can find all versions of the RPM spec files I've been using over the years here:

https://github.com/otfried/ipe-tools/blob/master/obs/ipe.spec

Feel free to use this to run rpmbuild on your own machine to create packages for your users.

---

You say you were able to compile once. On debian-based systems, you would then be able to run make install inside a checkinstall harness, and besides installing the software locally, it would also build a deb package that you can then install on other machines with the same setup. I assume something similar must exist in the RHEL world.