Le ven. 19 juin 2020 à 19:34, Paul Gevers <elb...@debian.org> a écrit :
> Hi Jérémy and Xavier,
>
> On 19/06/2020 13.33, Jérémy Lal wrote:
> > libnode68 and libnode72 can be co-installed.
>
> Sure.
>
> > /usr/bin/node is going to load the lib with the SONAME it's been built
> for.
>
> Of course, like any normal binary that is linked against a library in
> Debian.
>
> > So of course nodejs 12.x loads libnode72 and nodejs 10.x loads libnode68.
> > Otherwise the SONAME bump wouldn't be major.
> >
> > Paul: you're right to point out that it is perfectly possible for
> > another application
> > to link against libnode72 without needing to install nodejs 12.
> >
> > Xavier: i didn't think about that beforehand, but the approach you
> suggest
> > will break things (maybe other packages using libv8-dev, for example).
> >
> > I'm not sure why node-iconv depends on nodejs.
>
> As my other bug, node-expat seems to have the same issue.
>
> > Its autopkgtests should however depend on nodejs >= <version>
> > where <version> is the one built against the same libnode SONAME as
> > node-iconv (?)
>
> That doesn't scale, because it's every package that has an autopkgtest
> that depends on node-iconv that has this issue. So it's node-iconv that
> needs to declare the right versioned relation to nodejs. It looks like
> the binary executable already knows it, but the Debian package doesn't
> know it yet. The internal knowledge needs to be exposed somehow.
>
Since all packages that Build-Depend: libnode-dev are concerned,
maybe the solution is to declare:
libnode-dev
Depends: nodejs (= ${binary:Version})
- downside: packages depending on libv8-dev will install nodejs (this
shouldn't be a problem).
- a multi-arch issue ?
?
