Bug#919903: Package wxWidgets 3.1
Control: reassign 919903 wnpp Control: retitle 919903 ITP: wxwidgets3.2 -- wxWidgets Cross-platform C++ GUI toolkit Control: owner 919903 s...@techie.net wxWidgets 3.1 has finally evolved into the stable wxWidgets 3.2.0 release. Scott Talbert is already working on packaging it, so converting this into an ITP bug and making him the owner. Cheers, Olly
Bug#919903: Package wxWidgets 3.1
On Mon, Dec 23, 2019 at 06:21:53PM -0500, John Scott wrote: > > It's not ABI stable, so it's just not suitable for packaging. Every new > > 3.1.x release would mean a transition for everything built against it. > > Even if we only uploaded to experimental with the aim to support local > > builds, a new upload would break everyone's locally built applications. > > Upstream appears adamant that it's ready to deploy: > > Please notice that while 3.1.3 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. It's frustrating that upstream have invented this strange concept of a development version for use in production, and I've pointed out that it doesn't work for distros which ship binary packages to them. I've also tried to encourage them to start a new stable release series more frequently. 3.1.x is perhaps ready to deploy in a world where it's fine to build all your own dependencies and statically link them into your app which you ship direct to users, but that's a different world to Debian. > I hope you'll reconsider uploading to experimental. You're asking the package maintainers to take on a significant amount of extra work here, and I don't see that putting a non-ABI stable package into experimental is useful enough to justify that effort. People who really want to try a development version of wxWidgets (or anything else) can always build it for themselves. Then they get to decide when to update to the next 3.1.x and have to rebuild all their applications with the new version. > It appears that my trouble with wxMaxima is probably fixed in > wxWidgets 3.1.2 and I'd like to give it a try. If I'm following, this issue which made you want to try 3.1.x turned out to already be fixed in Debian unstable some months ago anyway, so the presence of an experimental package would if anything just have distracted. Cheers, Olly
Bug#919903: Package wxWidgets 3.1
Control: reassign 935141 libwxgtk3.0-0v5 3.0.4+dfsg-8 Control: affects 935141 wxmaxima It appears that my trouble with wxMaxima is probably fixed in wxWidgets 3.1.2 and I'd like to give it a try. > It's not ABI stable, so it's just not suitable for packaging. Every new > 3.1.x release would mean a transition for everything built against it. > Even if we only uploaded to experimental with the aim to support local > builds, a new upload would break everyone's locally built applications. Upstream appears adamant that it's ready to deploy: > Please notice that while 3.1.3 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. I hope you'll reconsider uploading to experimental. signature.asc Description: This is a digitally signed message part.
Bug#919903: Package wxWidgets 3.1
tags -1 wontfix thanks On Sun, Jan 20, 2019 at 05:24:50PM +0100, Yuri D'Elia wrote: > It would be helpful to have a package for the 3.1.* release (currently > 3.1.2) of wxWidgets for development purposes, even if that just targets > experimental. It's not ABI stable, so it's just not suitable for packaging. Every new 3.1.x release would mean a transition for everything built against it. Even if we only uploaded to experimental with the aim to support local builds, a new upload would break everyone's locally built applications. People who want to use 3.1.x are better off doing a local install from upstream sources as then they have control of when they upgrade to a new 3.1.x. Once 3.1.x turns into 3.2.0, upstream promises ABI stability and then we can usefully package it. > Although still considered "development" and not 100% compatible with > 3.0, wx 3.1 includes a plethora of bug fixes that forced me to upgrade > for development. Please encourage upstream to backport fixes for such bugs to 3.0.x. In most cases can pick up backported fixes and add them to the Debian packaging fairly easily (no need to wait for upstream to make the next 3.0.x release). Cheers, Olly
Bug#919903: Package wxWidgets 3.1
Package: wx-common Version: 3.0.4+dfsg-8 Severity: wishlist It would be helpful to have a package for the 3.1.* release (currently 3.1.2) of wxWidgets for development purposes, even if that just targets experimental. Although still considered "development" and not 100% compatible with 3.0, wx 3.1 includes a plethora of bug fixes that forced me to upgrade for development. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (900, 'unstable'), (800, 'experimental'), (500, 'unstable-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-1-amd64 (SMP w/8 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages wx-common depends on: ii libc6 2.28-5 ii libgcc1 1:8.2.0-14 ii libstdc++68.2.0-14 ii libwxbase3.0-0v5 3.0.4+dfsg-8 Versions of packages wx-common recommends: ii zip 3.0-11+b1 wx-common suggests no packages.
