wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release.
For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already).
On Mon, Sep 12, 2022 at 10:32:23PM -0400, Scott Talbert wrote:
wxWidgets 3.2 (a new API/ABI stable release) has been released a few months >> ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped >> supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx >> package users to wxwidgets3.2 for bullseye, with the plan to remove
wxwidgets3.0 before release.
For most packages, the transition should be as simple as changing
Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages >> may require small patches; I'm happy to help with those (and I have some
already from working on this transition in Fedora already).
Question from somebody who doesn't know wxWidgets: if the update from
one release to the other is so simple (at least, you make it sound very simple, and #1019416 has no blocking bugs, so I reckon everything
works?) then why is this not packaged like pretty much any other library
with an unversionde source package and an unversioned -dev binary
package?
Major wxWidgets releases are not API compatible, so there will be packages that will require changes (although there are not many
backwards-incompatible API changes between 3.0 and 3.2). I would think of
it more akin to GTK-2 vs GTK-3, although there are not as many API changes. Historically, there have been larger API changes between releases (e.g., 2.8 to 3.0).
I suppose it would be technically possible to do it with a single -dev package, but that would lead to potentially extended breakages of unstable while the packages that require changes get updated.
For most libraries, the deciding factor would be: are library users
expected to find the library via a single pkg-config file that cannot
coexist with the other version (like libpng's libpng.pc and OpenSSL's libssl.pc/libcrypto.pc/openssl.pc), or do they ship versioned pkg-config files that can coexist (like GTK 2/3/4, Qt 4/5/6 and SDL 1/2)?
For most libraries, the deciding factor would be: are library users
expected to find the library via a single pkg-config file that cannot
coexist with the other version (like libpng's libpng.pc and OpenSSL's
libssl.pc/libcrypto.pc/openssl.pc), or do they ship versioned pkg-config
files that can coexist (like GTK 2/3/4, Qt 4/5/6 and SDL 1/2)?
A more technology-neutral way to ask this question is: when the library
user names the library that they want, do they do so with a major-version-qualified name, or with an unversioned name?
For libraries like GTK and SDL, the answer is that they normally use a major-version-qualified name: Autotools PKG_CHECK_MODULES([GTK], [gtk+-3.0]), Meson dependency('gtk4'), CMake find_package(SDL2 REQUIRED) or similar. Because names are interfaces and interfaces are names, we package these libraries with correspondingly versioned names: libgtk-3-dev, libgtk-4-dev, libsdl2-dev and so on.
For libraries like libpng and OpenSSL, the answer is that they normally
use a non-versioned name: Autotools PKG_CHECK_MODULES([openssl]) or Meson dependency('libpng') or similar. We package these libraries with unversioned names: libssl-dev, libpng-dev and so on.
I think following that principle would make me lean towards a -dev package without the major version, because library users seem to ask for it with dependency('wxwidgets', modules: ['core']) or WX_CONFIG_CHECK([3.0])
or $(wx-config --cflags --libs core) or something like that - where the
3.0 is a minimum version, rather than a major version to select.
wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. …
For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. …
Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
libalien-wxwidgets-perl
On Mon, 12 Sep 2022 22:32:23 -0400, Scott Talbert wrote:
wxWidgets 3.2 (a new API/ABI stable release) has been released a few months >> ago and is now packaged in unstable as wxwidgets3.2. …
For most packages, the transition should be as simple as changing
Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. …
Debian Perl Group <pkg-perl-maintainers@lists.alioth.debian.org>
libalien-wxwidgets-perl
libalien-wxwidgets-perl (.69+dfsg-4 uploaded to experimental.
Next step: check what libwx-perl [0] says and do a binNMU or sourceful
upload (it needs to switch from wxperl-gtk-3-0-5-uni-gcc-3-4 to wxperl-gtk-3-2-0-uni-gcc-3-4).
Reviews of the packaging changes welcome.
Hi,[...]
wxWidgets 3.2 (a new API/ABI stable release) has been released a few months ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx package users to wxwidgets3.2 for bullseye, with the plan to remove wxwidgets3.0 before release.
For most packages, the transition should be as simple as changing Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages may require small patches; I'm happy to help with those (and I have some already from working on this transition in Fedora already).
On 2022-09-13 Scott Talbert <swt@techie.net> wrote:
Hi,
wxWidgets 3.2 (a new API/ABI stable release) has been released a few months >> ago and is now packaged in unstable as wxwidgets3.2. Upstream has stopped >> supporting wxWidgets 3.0, so the Debian wx team would like to migrate all wx >> package users to wxwidgets3.2 for bullseye, with the plan to remove
wxwidgets3.0 before release.
For most packages, the transition should be as simple as changing[...]
Build-Depends from libwxgtk3.0-gtk3-dev to libwxgtk3.2-dev. Some packages >> may require small patches; I'm happy to help with those (and I have some
already from working on this transition in Fedora already).
A successful build is no guarantee for a working packaging though. e.g.
hugin errs out immediately when built with the newer wxWidgets.
libalien-wxwidgets-perl (.69+dfsg-4 uploaded to experimental.
Next step: check what libwx-perl [0] says and do a binNMU or sourceful upload (it needs to switch from wxperl-gtk-3-0-5-uni-gcc-3-4 to wxperl-gtk-3-2-0-uni-gcc-3-4).
Reviews of the packaging changes welcome.
Thanks! Looks fine, other than a Build-Depends on wx-common isn't necessary - libwxgtk3.2-dev will pull that in.
On Thu, 15 Sep 2022, Andreas Metzler wrote:[...]
A successful build is no guarantee for a working packaging though. e.g. hugin errs out immediately when built with the newer wxWidgets.
That is certainly true - and probably another good reason we don't use the single-dev-package approach.
Do you want help with those errors?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 360 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 128:35:48 |
| Calls: | 7,686 |
| Files: | 12,828 |
| Messages: | 5,711,088 |