Quoting Alec Leamas (2021-09-26 12:16:00) > On 26/09/2021 11:08, Jonas Smedegaard wrote: > > Quoting Alec Leamas (2021-09-26 10:05:04) > >> Thanks for taking time to try to sort this out! > >> > >> On 25/09/2021 18:52, Jonas Smedegaard wrote: > > >> Tight dependencies should be fine. This is C++, so library symbols > >> is bit convoluted. > > > > See https://wiki.debian.org/PkgKde/DhSymbolsFile > > After some tries in this area I have leaned to Russ Allberry's post > https://www.eyrie.org/~eagle/journal/2012-02/001.html. Is this > outdated? Russ Allberry tried to provide more intimately track individual symbols, but for the packages he did the experiment he considered it too much work for too little gain, so he reverted to tracking stable ABIs. Others have come to different conclusions for different packages - myself included. I bring it up here - despite Russ finding it unsuitable for his package maintenance work - to help you explore options _beyond_ the conventional wisdom of "only rely on stable ABIs. > >> 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: > > > As for postponing, it's just about that if 3.2 arrives in time there > is nothing to discuss, and the issue is void. But OTOH, we could > always discuss things anyway, agreed. I deliberately ignored the timing part of your proposal, and instead think in "stages" - here is a plan I find sensible: * maybe you make an test packaging of 3.1.5 - not uploaded to Debian at all * if wxWidgets 3.2 is in Debian when you are ready to upload to Debian, then have your package link against that * if not, then you approach the wxWidgets maintainer about creating a package for it, which would stay in experimental until no longer experimental (i.e. when either ABI has stabilized or packaging contains reasonable tracking of unstable ABI e.g. using symbols tracking). * if wxWidgets maintainer find it unreasonable to package wxWidgets 3.2 before its ABI has stabilized, you might consider embedding a snapshot in your own package - released only to Debian experimental. * of there is still no wxWidgets 3.2 package in Debian when Debian gets close to freeze **AND YOU ARE FULLY WILLING TO MAINTAIN YOUR FORK OF WXWIDGETS YOURSELF FOR SEVERAL YEARS**, then release your experimental package to Debian unstable. * otherwise wait until wxWidgets maintainer consider it reasonable to provide the needed version of the wxWidgets library. > >> How do you and OpenCPN upstream expect to handle bugs for that > >> specific embedded version of wxWidgets? > > [upstream hat on] As for maintenance, using 3.1.5 places us in a loop > with wxWidgets upstream where possible patches introduced will be > forwarded, reviewed and eventually released with 3.2. This is also how > bugs will be handled. You are describing a healthy relationship between a code fork and its upstream origin. That's great to hear - it means your fork will likely be in good shape for as long as it needs to exist. My concern is that there is a real risk that you will need to maintain it for longer than you intended if you release your code to Debian unstable and let it migrate to Debian testing, and if that happens that you cannot maintain a _stable_ fork - i.e. that you 2 years from now will need to rebase your fork on a newer upstream snapshot to fix some bug that is too difficult for you to rebase and that upstream has progressed too far away from to care about solving it twice - both for their own codebase and again for your (to them) ancient codebase. > > 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. > > As long as we don't miss Bookworm it's not that bad. It will still > affect downstreams like Ubuntu and Raspbian, though. However, > question is how much effort we should put in this, since we still > don't know if 3.2 will arrive in time or not. I understand your concern for your codebase to get into stable Debian. My concern is that stable Debian should stay stable: Debian testing is supposed to _always_ contain only release-ready packages (the word "testing" relates to the state of integration _across_ packages, not to each individual package) - i.e. you should only ever let packages you maintain slip through into testing that you are prepared to maintain as stable for several years. > > 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. > > I totally agree with you that embedding is the last option and should > be avoided if possible. After all, I'm raising this issue in time... > > I also share your view that if bundling, it must be a temporary > measure. It must definitely not linger in upcoming releases. Sounds like we agree, then - sorry if I mistook you as less careful in my previous remarks... > Is there a route where we keep things in experimental (bundled or not) > and let it stay there until wxWidgets 3.2 is out? And we then can make > a sid package without any other dependencies or bundled wxWidgets > code? I think the route I outline above covers what you describe here - do you agree? - 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