[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bundling

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 

* 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 

* 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 
  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 

 - 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

Reply to: