You are not logged in.

#1 2021-02-22 15:38:35

Registered: 2020-12-23
Posts: 4

PKGBUILD RFC: making different versions of wxWidgets coexist

Hi! I'm currently developing an application using wxWidgets, a cross-platform GUI library. While developing I ran into the issue that the latest "stable" 3.0 version that the official wxgtk packages ship does not have XDG File Layout support and I found out that the 3.1 version of the API does. I can't install wxgtk-git from the AUR either because it conflicts with wxgtk and I can't uninstall wxgtk either because I use Audacity which depends on it. So I set out to try and resolve these conflicts to have both 3.0 and 3.1 installed, and while I'm at it find out whether it would be okay to push them as official packages, that's why the Request For Comments.

Now, I know that 3.1 isn't on the official packages because it's technically not a "stable" version, however I think it has a similar situation to that of the libreoffice-still (7.0) and libreoffice-fresh (7.1) packages, altough in this case it's a library instead of a program.

Some considerations:

- Version 3.0 of the API was released back in 2013 (source, third paragraph), during which a lot of useful features have been implemented in the library, one of which is XDG Layout support.

As the result of all this work, we are close to making 3.1.5 which should be the last release before 3.2.0 which will become the new stable version, after 3.0.0 released back in 2013. It will have too many enhancements and improvements to list in this blog post without turning it into a book

- The wxWidgets website actually recommends using 3.1.4 in production (source, second paragraph).

Please notice that while 3.1.4 is officially a “development” version because it is not fully compatible with the “stable” 3.0.x, the list of backwards incompatible changes is very short, so you shouldn’t have any problems updating to this version from 3.0.x in practice, and you’re encouraged to use this release, including in production.

- How the wxWidgets Version Numbering Scheme works (source):

The Version Numbering Scheme

wxWidgets version numbers can have up to four components, with trailing zeros sometimes omitted:


A stable release of wxWidgets will have an even number for minor, e.g. 2.6.0. Stable, in this context, means that the API is not changing. In truth, some changes are permitted, but only those that are backward compatible. For example, you can expect later 2.6.x releases, such as 2.6.1 and 2.6.2 to be backward compatible with their predecessor.

When it becomes necessary to make changes which are not wholly backward compatible, the stable branch is forked, creating a new development branch of wxWidgets. This development branch will have an odd number for minor, for example 2.7.x. Releases from this branch are known as development snapshots.

The stable branch and the development branch will then be developed in parallel for some time. When it is no longer useful to continue developing the stable branch, the development branch is renamed and becomes a new stable branch, for example: 2.8.0. And the process begins again. This is how the tension between keeping the interface stable, and allowing the library to evolve is managed.

You can expect the versions with the same major and even minor version number to be compatible, but between minor versions there will be incompatibilities. Compatibility is not broken gratuitously however, so many applications will require no changes or only small changes to work with the new version.

So I think that just like with the libreoffice packages we could have both "stable/even" packages for established applications and "development/odd" packages for new applications and applications that need new features.

There are two conflicts that need to be resolved for the packages to coexist and I have worked with upstream to fix them (mailing list thread).

The first one had to do with adding release suffixes to gettext catalogs, which is necessary for runtime, which has been resolved with this commit that has already been merged with upstream.

The second one has to do with some development utilities, about which the maintainer told me that they want to keep the filenames as is if possible. After some research I concluded that the 3.1 version of these utilities are backwards compatible with the 3.0 version, these are not needed for applications to run, just for development. So my idea is that the simplest solution would be to have a third flavor agnostic package that ships these utilites, but one of them will depend on the development package base library. Both stable and development packages would need to pull this one just for the utils. Let me detail a little more, these are the files that would be shipped with the utils package:

- /usr/share/aclocal/wxwin.m4 - A m4 file
- /usr/share/bakefiles/presets/*.bkl - some Bakefile scripts
- /usr/bin/wxrc - This is a program to zip xrc resource files (source), it will depend on the 3.1 libwx_base* libraries, even if you just want the stable packages you would still need to compile the development packages
- /usr/bin/wx-config - is a symlink to a script that is generated according to build configurations /usr/lib/wx/config/gtkx-unicode-3.y, where x is the gtk version and y the wxWidgets minor version, which is a script that returns the right compiler and linker flags given the desired configuration, these scripts are pretty much identical to each other except that they define a default version to use but they can detect other of their own and you can specify which one version you want to use through any of them, even versions newer that themselves I think, what I'm trying to say is that if such a script was generated with 3.0 you can still call a 3.1 script through it, in the end it's about deciding which of these scripts to symlink, I would choose the stable gtk3 3.0 one, and pass --version=3.1 to get the right flags as long as 3.1 is a development version

Anyway, I think that the wxrc solution isn't too good, since it implies compiling wxWidgets 4 times, for each gtk version and wx minor version. That is compiling about a million lines of C++ 4 times. Each one of them takes about 5 minutes using all of my 12 i7-9750H threads. I don't know if it would be possible to ship these as compiled binaries nor what are the requirements to ship them as such, let me know if you do.

Here's the repo where I keep the PKGBUILDs that I wrote, these are based on the current official PKGBUILD. … s-packages

I've commented out the dependencies as I was testing the PKGBUILDs on a VM with a fresh Arch install, and finding out which packages I needed to compile. I determined these using the script which runs find-libdeps on each create package and prints the dependencies as packages. I think these should do, but I don't know if this is the proper way to determine dependencies, nor if they are makedepends or optdepends. The wiki said not to rely on transitive dependencies so I only rely on transitive dependencies that I'm aware of inside the PKGBUILD, you might see that I omitted some dependencies that are already pulled by gtk-common.

Sorry for the kinda long post and thank you for your help and comments.


Board footer

Powered by FluxBB