Le ven. 3 juil. 2020 à 20:53, Jonas Smedegaard <jo...@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
