Hi Alec,

Quoting Alec Leamas (2021-09-25 17:47:04)

Trying to plan the future for the OpenCPN package. Upstream is
currently shipping a beta, and eventually it will be released and
packaged.

In next cycle upstream might update the wxWidgets dependency from 3.0
to 3.1.5. This is problematic, since wxWidgets offers no ABI stability
for odd-numbered releases like 3.1 and there is thus no Debian
packages available.

Now, normally this should not be a problem since the upstream 3.2
release is due Real Soon, and OpenCPN has rather long cycles release
cycles, roughly yearly. However, upstream wxWidgets seems stalled, and
we are probably facing a real risk that 3.2 is still not available for
next OpenCPN release in about a year.

So, the question: would it be acceptable to bundle the wxWidgets 3.1.5 sources in next OpenCPN release in such a situation?

Thoughts?

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.


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============g48824797609446260=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFPSJcACgkQLHwxRsGg ASESjg//TXmtQl/ETyKBg9Z1UYO/nRtLHa+7hhMJJQrSJV3lA11kLqIocbVJ/6/5 tRcuDkjv57nvvr83uyC6tZTT9LsYaa4CmgNxw0BDbPtofK6/VWuxhkJKOmFaM5YB 2sjjHSeBJipdFOF8wNwxeSKwjIsG5W+Gm7BT8ekf8DVukBPxu1pIzbw+4tntAKZL 8ss/g4yDtlC0g6SeqR4ukMBQjGyGdywVzrO+ygcEcussgi9RFEtWz+R3x5Kne04/ +FeeGeK1+K0Rbpb6guS5DLMCF/0UR5JIbQ3xroPh3w493QoUdiBDdoKCUQ0skTNh ol2eaIDKf3h4sKSt27MnMAHMPkpWs018utkNQV8pyhCJD7oKJLbJGE7oeWmwZ5s3 YYX9AwwUMiiXBV1ayF53KEsesqNoLgtWw8oXFkdvgqBTYZXsSLKXCPKdTijPVAJt 3Gb2n9e1mr9KbF59lm0hpi0TOcEHDVlU62ASgW86wJ+57lGAYDFwgD2d58jZzPHQ 009Pq2Y4aZ0UIusa5

Dear list,

Trying to plan the future for the OpenCPN package. Upstream is currently shipping a beta, and eventually it will be released and packaged.

In next cycle upstream might update the wxWidgets dependency from 3.0 to
3.1.5. This is problematic, since wxWidgets offers no ABI stability for odd-numbered releases like 3.1 and there is thus no Debian packages
available.

Now, normally this should not be a problem since the upstream 3.2
release is due Real Soon, and OpenCPN has rather long cycles release
cycles, roughly yearly. However, upstream wxWidgets seems stalled, and
we are probably facing a real risk that 3.2 is still not available for
next OpenCPN release in about a year.

So, the question: would it be acceptable to bundle the wxWidgets 3.1.5
sources in next OpenCPN release in such a situation?

Thoughts?

--alec

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Jonas,

On 25/09/2021 18:04, Jonas Smedegaard wrote:

Hi Alec,

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?

--alec

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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)


- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private --==============14012960639829317=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFPU8gACgkQLHwxRsGg ASHxPw//WkUkZhlG/tEg9WSd18pbs0RXFXokRqmV8YM1sASuX0psYDthwDHGXqo9 UAshAdtLUz0vMDW1ITwnMXNpgi1pWxgV35TDcfXXqYc0AK1ct46lzpcvk83IuM1X +oUhtP6YHch1UjHGRqxuHe1saRMfxRhHunL2v9knTS2ZdaasnVELWGndmSAThotr lWpGq/bf4kRjXRIUN91Yt1TJxK10NqRvGW7zkzElHo4lc7jMrEMtWqcbJYYSa64Y xmKRs10/VE96FleEsOhJZJQVxoKNGqNc5H6tem2aJU0ldB1G4CHM09KO392GPZ4G jhmIQE9pCVs0Uy1w/8YTXIIhp7k2llijQigwoxwaCU3beUKYfSKrDq5mWlxQpWSq qQ1ZscsFDV1OdNk95dwhG2QmnG/aIMOMHvOCoMjWo58m4DvgWJal7FuHmxCb8RPn kYH+d1XL2shz1XOjDYpT1dkma/IqnDWgtVze73QgBVA95Lxb30FPaYtTwNhYLG6Z QbzoNu5/CztvHWBvC

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.

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.


Thoughts?
--alec

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 --==============$46731504641668126=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFQOHgACgkQLHwxRsGg ASF2tg/+JGnJi4BoAAdzws+iWql0DGnJMdwKA4XiYDGzYdiUzBmlaacpRb0MEOIJ 5NpZjwv0OxNojgElSJcRheJiHP/zaNdMPngDYvtcYbcfocDh8eLcEwkItw/dlQOG 5ehy6lGgBOUJuWIs4Xto//PRJE6Aws2sGlHtRWecAx3XEvQ0z9KImViLsJ8aDwzc itNKk4YEjp4Q+ZXJcrtiOKp7YbPB8N0HC7xaCc4gQQuqcTQzjHLP/1HPDfuD9XFL by87lHBv1Ow/VDwsrYfQIydNT3wdIS/1nOTg+Hqzm8aPpUxE2ce/+Tl5T0SHiUkS Vz1Ih5etN9ILEB61KMDF+R5EkXecpawJ+w1w+3dvW/bo+jof/qkbIExPDXtg1R+G JvfO4TQbO8TcP1lHK59o+f3CbgarR1zc6LzwMIpJaetLW0qmHpN8oTULrpu22ZhQ NSOMnoxgITjy5vBoG46C8EAgHKYUlrVooerar21nr+scpE+ptN/0+dvBnIYau99t cwfBk2EYsQyHSTyDP

On 2021-09-26 12:16 +0200, Alec Leamas wrote:

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?

That KDE tool does help a lot but for large C++ packages symbols files
are so large as to be of limited usefulness IMHO. If you are upstream
too and actually know which symbols should be coming and going then
they can have some utility as a check, but if you are just a packager struggling to keep up and all you ever do is generate a new one (as
opposed to checking to see if the changes make sense) then I can't see
the point.

Having a much simpler shlibs file is more maintainable, and may be
sufficient to track basic ABI/APi compatibility.

Is there a route where we keep things in experimental (bundled or not) and let it stay there until wxWidgets 3.2 is out?

Yes. This is what I'd do for the time being. That way you are not
committed to this path where you might end up maintaining (or not
maintaining, just hoping for the best on!) an unstable wxwidgets
version for several years.

Wookey
--
Principal hats: Linaro, Debian, Wookware, ARM
http://wookware.org/

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEER4nvI8Pe/wVWh5yq+4YyUahvnkcFAmFQTA4ACgkQ+4YyUahv nkdA0w//bat4aWre7ZBUh8Cy5D/hL354Lpcnr3Csiu09MWS2tpvrZ4c6ZpYPyykQ NiLu4YhSefLoiXWaHsgdAdlHtwACVcgrLfFuPFmSkpApw5ogQQQ7awkzfdHUPCBF Y0w6nfNxZTb/j8nrSBjddOL8pTGQGpAlaRu0aYfxNvlDzbXLazrHiXerkf/deB9B cyHNFk4GZYhqBUNrOmmGumBgj7w2T46OxZg4tqQ1yVUwV++vG58r40U7wfKlX9QM TQI9XtMcmmtsb/JnZzHH6BR96u1s4fNzaYtisvcou4rrAUPwQonGUYjmZtKHxWZI IVLUQGMJQ844/iTCpNUNuycodqWFsupvXyfp+WpYmEVumUFx4EE9s8/JXoeWoejO kQfm9ync3vQvOz0zPlS/pDRcRsSp6voBP5PyBOSdjFBkEOnf6rZ4U0PIK7q1NyTD TzEwwUuqjCRkGPkVe7HOK6qTO+L6HwLTh8CVgOO4U2GaHc5+ARPGBlKom7fsv4E2 oazF/8NJeNw2JP84QRgUnxn2xUbYfQt9axX7ejOLadtNWuLKp17MSl9S5pOh0wfu z/papCfTFFgvEtRdjCKkg8nLhiT6vL1z10wBig43G8ULP9nWWNIe1qYbe7BiQ5R3 28HJBPByYaPFGS3PQ8MoeQ3Lb6jMGSOafROdvhcpHHv7MdkFZSw=
=1fDi
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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 --==============p80136033846497211=MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Description: signature
Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmFQalsACgkQLHwxRsGg ASEVUw//QRUGpIb68lyfjaLMJSkuLA+3Xjg2aFZNPCwwbKjiJCJv0OD8FrT13Q/m bdqCKFfntQ6QyY3+mcHmsXTU0//8UOnIS0x7/xz2KW9Ce13u3+80ujlZRyLWQI6N jrawq42ef4NFp+DJxkgWOGQCMIkQMq9eqECEYgmsTkLdU3Ea98CfSmBZU6LpoJlN tclniCfTKHhUcIbCEyVhtnfacuKpPz3LwqXmbCqtyY9sPu+3hZ3WO+qih3JvzNbc 5eKX7qoaLdKpNFy4iAhGT1O2QfzbwKCiCWIF3j8gUrqgPyujZAb1s3P/m8M0aUII ZhqxYdBVCm2k/g0+Ht+2gvUay5H1KHXwIqDJYJ6ZaDqQ20RaEzb0+eLH3FN3lX+a Ob1zzvJE6Qo99MyoB2z3iHSVM4KAA2fA0cwnPmjxZMUC4eGfwO4pn8G10rT+Hkvf IndSvsgchc6/QNJJyp194ch2RPEp89/tBBScRAAohxBtft8IELNW+K+zfGayuQmS dDyjM85fvX4LQB1F3

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 26/09/2021 19:03, Alec Leamas wrote:

Hi Jonas,

On 26/09/2021 14:41, Jonas Smedegaard wrote:

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.

Just for the record: the issue about packaging wxWidgets 3.1 has already
been discussed with the maintainer:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919903


--alec

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Sep 30, 2021 at 10:24:01AM +0200, Alec Leamas wrote:

Just for the record: the issue about packaging wxWidgets 3.1 has already
been discussed with the maintainer:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919903

Hi Alec, I get the impression there that the maintainer is strongly
indicating that they think it's not worth it, but that doesn't
necessarily rule out being ok with you maintaining the experimental
uploads.
--
emorrp1

-----BEGIN PGP SIGNATURE-----

iHUEABYKAB0WIQSBP39/Unco6Ai78+TbymUJHySObAUCYVW7DwAKCRDbymUJHySO bH9hAP4qzpn0We3JaUbqTvd0cpubyM66fK87/hxRe7BsuR1xpQD7B33ukRCMpngl M43JNdO7ubaMCVb2vWjk8Ij859Pe4gw=
=nSng
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)