Quoting Alec Leamas (2021-09-26 10:05:04) > Hi Jonas, > > > Thanks for taking time to try to sort this out! > > On 25/09/2021 18:52, Jonas Smedegaard wrote: > > Quoting Alec Leamas (2021-09-25 18:23:42) > >> On 25/09/2021 18:04, Jonas Smedegaard wrote: > >>> Quoting Alec Leamas (2021-09-25 17:47:04) > >>>> > >>>> So, the question: would it be acceptable to bundle the wxWidgets > >>>> 3.1.5 sources in next OpenCPN release in such a situation? > >>>> > >>> > >>> How do you and OpenCPN upstream expect to handle bugs for that > >>> specific embedded version of wxWidgets? > >>> > >>> Sounds more sensible to me to (coordinate with wxwidgets maintainers > >>> to have) wxWidgets 3.1.x packaged as a separate package, tracked > >>> with its proper upstream source. Then when we get near freeze it > >>> can be assessed how many of the wxWidgets branches we want to > >>> include with the upcoming stable Debian release - and include in > >>> that assessment how many packages reverse-depend on each. > >> > >> > >> My thinking so far has been that a wxWidgets 3.1.5 package just isn't > >> possible since there is no ABI stability guarantee. Am I wrong? > > > > Lack of stable ABI means that each library change may require > > recompilation of reverse dependencies. > > > > This can be handled in packaging either by declaring tight dependencies > > (see e.g. `man dh_shlibdeps`), or by tracking library symbols and use > > those to resolve dependencies (see e.g. > > https://wiki.debian.org/UsingSymbolsFiles) > > > Tight dependencies should be fine. This is C++, so library symbols is > bit convoluted. See https://wiki.debian.org/PkgKde/DhSymbolsFile > What do you think about a plan like this: > > - We make a provisionary, internal packaging of 3.1.5 and uses that in > next cycle. > > - Around February-March -22 we assess the situation again. If we > believe that 3.2 will ready and packaged before our own release, we > just wait for that to happen. > > - If not, we approach the wxWidgets maintainer about getting our > provisionary, temporary package in shape and released, probably in > experimental. > > - If the maintainer refuses to make such a release we have to bundle > the library in our own package. I am concerned that you a) seemingly prefer to postpone involving wxWidget package maintainers, and b) did not anwer my question about maintenance: > How do you and OpenCPN upstream expect to handle bugs for that > specific embedded version of wxWidgets? I think that if you do not want to properly maintain the wxWidget code you need, then the best for Debian is that you postpone introducing this newer OpenCPN release until the wxWidget package maintainers consider it reasonable to introduce the code needed for it. If what you call "provisionary" is something done outside of Debian or only in Debian experimental, then is seems you agree. But I am not sure - in particular your "and uses that in next cycle" sounds like you will not treat it as only experimental but rely on that newer release, no matter if embedded code is maintainable or not. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Attachment:
signature.asc
Description: signature