Hi Alec, On Fri, Oct 28, 2022 at 10:15:49AM +0200, Alec Leamas wrote: > Dear list, > > I'm maintaining the opencpn and libwxsvg packages. They both depend on > wxWidgets which now is updated to version 3.2 in testing. Hence, I have two > bugs [1], [2] requesting an update of my packages. > > The core issue here is opencpn, wxsvg is a dependency. The problem with > opencpn is that it has a plugin universe, and updating the current 5.6.2 > version to wxWidgets 3.2 would break the plugin ABI.
Is this breakage due to wxWidgets or due to other upstream changes? If the latter, *it might be* possible to backport the wxWidgets patches, however whether that is feasible I don't know… > The upstream plan to handle the ABI break is to do it when releasing next > version 5.8.0 which is going into beta in November and will be released > before Christmas. My thinking has been that if opencpn 5.8.0 is uploaded > before Christmas the update process should be ok, since the wxWidgets 3.2 > version will be uploaded before the freeze. > > Opencpn (current master, upcoming 5.8.0) builds fine using wxWidgets 3.2. > > However, I get nag messages that opencpn will be removed from testing at > November 8 unless I update it to using 3.2. Obviously, this makes me > nervous. Questions: > > 1) Is my overall plan ok? I guess this *might* work; Soft-Freeze is gonan be 2023-02-12, if they package is not in testing at that day, it won't be in bookworm. So there is some risk if any delays are happening with upstream release timeline… > 2) If so, how handle the threat of being removed from testing? Don't see that as a threat. Sure it is annoying but testing removal is temporary and as you package will be still in backports, people should be able to install from there, if they are on stable… If they are on testing, well, that is the peril of testing. Evenutally the release team will force the removal of wxwidgets, regardless of the bug; for exact timing you might want to reach out to the people driving the transition and ask them… More generally, any response to a release critical bug will restart the removal timer. So if you reply to the bugs below, and document the plan, this will reset the timer, so you can delay the automatic removal a bit. However, that will not stop the release team for manually removal; contrary, they might be unhappy if people using this as tactic to delay autoremovals, as this creates work for them. Said that, a reply to the bug laying out the plan should be done anyways, because this is useful information for many… (If there is an upstream discussion, set the Forwarded: BTS metainfo to link to that discussion) -- tobi > Cheers! > --alec > > [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019769 > [2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1019765 >
