Re: Bundling
Hi Jonas,
On 26/09/2021 14:41, Jonas Smedegaard wrote:
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.
OK, thanks.
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.
OK, see below.
>> 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.
Agreed, we should not do that, se below.
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...
No offense taken ;)
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?
Yes, besides that I don't really consider releasing the experimental
package an option. At least as it looks now.
Thanks for all input, I think we are reaching some consensus here. There
is a plan...
Cheers!
--alec
Reply to: