wxWidgets: Cannot Install Different Versions Side-by-Side

[AntumDeluge]

wxWidgets is split into separate PKGBUILD scripts by base version & some of the produced packages conflict with each other. This makes it impossible to use a single PKGBUILD script to produce multiple packages of a software built against the different wxWidgets versions.

$ pacman -S mingw-w64-x86_64-wxwidgets3.0-msw mingw-w64-x86_64-wxwidgets3.2-msw
resolving dependencies...
looking for conflicting packages...
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: mingw-w64-x86_64-wxwidgets3.2-msw and mingw-w64-x86_64-wxwidgets3.0-msw are in conflict

I came across this issue with building wxSVG recently. The current options are to have only one wxSVG package built against a single wxWidgets version (likely the most recent, see: #12578) or create unique PKGBUILD scripts for each (see: #12559).

There are other packages that may suffer from the same issue, such as wxPython. The current wxPython package is built against wxWidgets 3.1 (wxPython4.0 is built against wxWidgets 3.0).

[stahta01]

Add an "-utils" package for each wxWidgets version would help or maybe even fix this problem. The "-utils" package would contain the non version suffix version of wx-config and wxrc commands. The package wanting to use two different version of wxWidgets would then need to use the version suffix commands. And, skip the installation of the "-utils" packages.

NOTE: It does currently allow packages using two different wxWidgets versions to be installed at the same time. It just does not allow package(s) to be created for two wxWidgets versions at the same time.

Tim S.

[mmuetzel]

Is it necessary to build packages with different versions of wxWidgets? IIUC, it is kind of a development toolbox that projects can use for their GUI. Does having the option to install the same package built against different versions of wxWidget any advantage for the end user over distributing only one? IIUC, Qt is a similar toolbox (from a packaging point of view). Other packages are built only against Qt5 or Qt6. Minus the packages that are development tools themselves. Afaict, these development tools are built in separate PKGBUILD rules (instead of split packages). E.g., mingw-w64-pyqt5 and mingw-w64-pyqt6. Could wxWidget follow a similar approach? Or am I missing the point?

[stahta01]

It allows the person writing the client code to follow the standard wxWidgets build directions. Other wise the people who follow the standard directions will have build errors. So, either more complaints or more people bad mouthing the package will result.

Tim S.

[mmuetzel]

Sorry, I didn't understand your response (and wasn't aware that there were people "bad mouthing the package"). Just to help me (and maybe others) understand: What are the "standard directions"? Is wxSVG one of those "development packages" that would be used to build other projects downstream? In case it is: Would separating the build rules for wxSVG into two separate PKGBUILD rules (for wxWidgets 3.0 and wxWidgets 3.2) resolve this problem? Or would that be impractical for other reasons?

[stahta01]

The standard directions use "wx-config" to build wxWidgets projects!

Tim S.

[mmuetzel]

Ok. To summarize what I understood so far: We need to install wx-config to allow projects to use that tool with a default name. Both the wxWidgets 3.0 "development" package and the wxWidgets 3.2 "development" package need to install it with that name. That means they cannot be installed at the same time. The original question was whether it would be possible to have them installed at the same time. (It's not if I understand correctly.) Your proposal was to add "-utils" packages to solve this. I'm still not sure I got the whole picture. How would that help? Or what am I missing?

[stahta01]

The two different "-utils" package will allow the conflicting files to have only one set installed at a time. The meta package "wxWidgets" will by default install wxWidgets 3.0 for now alone with the wx-config from wxWidgets 3.0. This will allow the old [standard] directions to work. At some future time the meta package changed to wxWidgets 3.2.

The msys2 packages will never install "-utils" packages and instead will use wx-config 3.0 and 3.2 files instead.

Tim S.

[mmuetzel]

How would that help with the original question (build wxWidget 3.0 and wxWidget 3.2 variants as split packages in a single PKGBUILD)? IIUC, both "-utils" packages would be necessary as a build dependency to support the "standard directions". But these packages would still conflict IIUC...

[AntumDeluge]

It should also be noted that there is a wxWidgets 3.1 package. I didn't include it in the original post because it hasn't been converted to a split package yet & thought it might just add confusion. If I remember correctly, it does not have any conflicts with the 3.0 & 3.2 packages.

Is it necessary to build packages with different versions of wxWidgets?

Unfortunately, software using wxSVG may have compatibility issues between different wxWidgets versions. An app I am working on supports wxWidgets 3.1 & 3.2, but not 3.0. So I need a version of wxSVG that is built against either version 3.1 or 3.2. While some other apps may require compatibility with 3.0.

Whether or not a single wxSVG package can be built that is compatible with all three, I don't know. That is beyond my scope of understanding. I am guessing that is what @stahta01 is talking about, but not sure.

Would separating the build rules for wxSVG into two separate PKGBUILD rules (for wxWidgets 3.0 and wxWidgets 3.2) resolve this problem?

That was the solution I came up with in #12559. But that introduces the issue of duplicating files, such as patches, for each PKGBUILD script (unless they are hosted somewhere for each PKGBUILD to download).

[stahta01]

I can move the files into the optional "-utils" package that normal users will only install a single version of it. And, the MSys2 packages will not install any of the "-utils" packages. I give up on this thread fixing any thing because I consider it a waste of time because someone will complain about the solution. Or you could go with the option of just removing wx-config and wxrc.exe from all but one package; this will result in newbies and others complaining!

Tim S.

[mmuetzel]

I appreciate that you took the time to explain the situation. And I'm sorry you feel like it was a waste (it wasn't for me). My main intention was to help you make a good case for splitting the package again if necessary. (Since I saw that you encountered a bit of backlash because of that the last time.)

There will probably always be someone to complain. Imho, the goal should be to come up with a solution that doesn't impede some use cases, and that is the "least painful" for most use cases...

I misunderstood previously that wx-config needs to be installed with that name. If I understand your latest comments correctly, it is not strictly necessary to have it installed with that name to build dependent package. (It might be possible to tell these packages to call that program using a different name instead?) And you propose that this should be done in the PKGBUILD rules in this repository. That sounds reasonable to me. However, installing wx-config with that name exactly would help to build dependent packages with default flags (e.g., by downstream users of msys2). Is that right?

This might be similar to the transition from python2 to python3. I guess that during that transition, python changed from being an alias for python2 to being an alias for python3. We are probably in a similar situation with wx-config here. Which package installed the python executable back then? Could this transition be handled similarly? Or am I comparing apples with pears?