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

Re: help needed to resolve nodejs transition #963039





Le ven. 3 juil. 2020 à 20:53, Jonas Smedegaard <jonas@jones.dk> a écrit :
Quoting Jonas Smedegaard (2020-07-03 20:45:22)
> Quoting Jérémy Lal (2020-07-03 19:50:55)
> > I have a problem with the transition of nodejs:
> > from version 10 with abi libnode64
> > to version 12 with abi libnode72
> >
> > C(++) addons like node-iconv can be compiled using libnode-dev,
> > so installing an addon automatically installs the right libnodeXX version.
> > (all addons Build-Depend libnode-dev).
> >
> > One can install nodejs 10 along with libnode64, and build node-iconv
> > using libnode-dev 12 which links to libnode72.
> >
> > However, running node-iconv tests in the autopkgtests environment requires
> > the nodejs version that is linked against the same libnode abi (i hope that
> > part is obvious).
> >
> > But it's not the case: the tests are run with nodejs 10 from testing,
> > against a package
> > built with libnode72, so the module loading fails.
> >
> > Those failures seem to be preventing transition to testing (which is
> > understandable).
> > Two questions:
> > - how to fix the issue now
> > - how to fix the issue for good
> >
> > Thanks in advance for any help.
>
> Have libnodeNN include a symbols file tracking changes to the ABI, so
> that any C++ addon depending on a part of the ABI which changes gets
> tightened package dependency on that specific binary release of the ABI.

No wait, that's complete rubbish what I wrote above: We are talking
about new major releases of the ABI so a symbols file would simply be
reset completely - and also, what I was thinking should happen already
does happen: node-iconv depends on a specific libnodeNN.

Problem is (talking to myself here, you already know it) that we need to
ensure that node-iconv is only ever _loaded_ by that same node as it is
linked against.

Only way I can imagine ensuring that is to extend symbols/shlibs
handling to add Breaks (if that is even possible), or add breaks to the
libnodeNN package itself so that only one libnodeNN can be present on
the system at once.

In which situations do we need libnodeNN to be co-installable?

Some other program linking against libnodePP.
The only case i know of is the one where libnode-dev provides libv8-dev.
But the absence of cases shouldn't be hushhushed.
 


 - Jonas

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

 [x] quote me freely  [ ] ask before reusing  [ ] keep private

Reply to: