Re: Bundling
Hi Jonas,
On 26/09/2021 11:08, Jonas Smedegaard wrote:
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:
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?
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.
>> 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.
(I have too many hats here...)
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.
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.
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?
To me, this looks like a road forward (?)
Cheers!
--alec
Reply to: