libssl1.0-dev conflicts libssl-dev

[Dan Kegel]

[impact]

The libssl1.0-dev package conflicts with the libssl-dev package, so this leads to all packages that depend on libssl1.0-dev to conflict with all packages that depend on libssl-dev; as well as all packages that depend on those packages (and so on).

[test case]

On a Bionic system (or Cosmic), install libssl-dev, and/or any package that depends on it:
http://qa.ubuntuwire.org/rdepends/v1/bionic/any/libssl-dev

Then, try to install libssl1.0-dev, or any package that depends on it:
http://qa.ubuntuwire.org/rdepends/v1/bionic/any/libssl1.0-dev

see comment 15 for an example of some packages that are force-removed when installing libssl1.0-dev, due to conflict.

[regression potential]

TBD after fix is determined

[other info]

Original description:

---

The fix for https://bugs.launchpad.net/ubuntu/+source/nodejs/+bug/1779863
is, not surprisingly, somewhat traumatic for some users.

In my case, installing libssl1.0-dev causes libcurl4-openssl-dev, libssh-dev, and libssl-dev to be uninstalled, which makes some of our internal packages fail to build.

Commenting out universe from bionic-updates in /etc/apt/sources.list would work around this, but that's not going to fly for everybody.

nodejs appears to be the tail wagging the dog now, and that's rather uncomfortable.

ProblemType: Bug
DistroRelease: Ubuntu 18.04
Package: nodejs-dev (not installed)
ProcVersionSignature: Ubuntu 4.15.0-34.37-generic 4.15.18
Uname: Linux 4.15.0-34-generic x86_64
ApportVersion: 2.20.9-0ubuntu7.3
Architecture: amd64
CurrentDesktop: ubuntu:GNOME
Date: Wed Sep 26 11:03:51 2018
SourcePackage: nodejs
UpgradeStatus: Upgraded to bionic on 2018-04-30 (148 days ago)

[Dan Kegel (dank)]

When will ubuntu provide nodejs 10.x (said to depend on openssl 1.1)? cosmic would be none too soon.

(I kind of wish Debian and Ubuntu allowed simultaneous installs of node8 and node10 ecosystems... e.g. by installing nodejs 10 to /usr/lib/node/10 and using node10 prefixes on package names, and using alternatives for the commands.)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Anthony Sottile (asottile)]

This seems to have been released with this breakage in 8.10.0~dfsg-2ubuntu0.3:

# apt-cache show nodejs | grep -Eo '(Version: .*$|libssl[^ ]*)'
Version: 8.10.0~dfsg-2ubuntu0.3
libssl1.0.0
Version: 8.10.0~dfsg-2ubuntu0.2
libssl1.1
Version: 8.10.0~dfsg-2
libssl1.1

[Anthony Sottile (asottile)]

The workaround in my case is to:

apt install \
    nodejs=8.10.0~dfsg-2ubuntu0.2 nodejs-dev=8.10.0~dfsg-2ubuntu0.2 \
    npm \
    libssl-dev

[Marco Scholl (traxanos)]

Before: It was partial broken (in some special cases)
Now: Node is completely broken on every system!!!!

please revert the stupid changes!!!

[Dan Streetman (ddstreet)]

@dank, nodejs isn't the only package whose -dev pkg (now) depends on libssl1.0-dev; I think you've misassigned blame and the actual title of this bug should be:

"libssl1.0-dev conflicts with libssl-dev (and deps), causing build failures"

> When will ubuntu provide nodejs 10.x

that version is still in 'experimental' in debian, and ubuntu pulls from debian.
https://packages.debian.org/search?keywords=nodejs

@traxanos, can you explain why you think "Node is completely broken on every system!!!!"

[Dan Kegel (dank)]

Doing version transitions of popular libraries is not rocket science. It's a hard slog.
I respect and thank the node and openssl maintainers.

I was not assigning blame, simply giving the symptom that caused my world to explode.

[Boris (kervyn)]

@ddstreet The problem for my use case is: I am not abled to install npm anymore, to use a dockerized ci, because the container do not build anymore nor to update our 18.04 containers.

I understand WHY you did it, but I didn't expect to get a broken LTS after half of a year. And a couple of packages on a standard "LAMP stack" (also for other non php web environments) depend on libssl-dev.

So my question is: how do I fix this in an automated way on several hundred container? Do I really have to package my own stuff? Do I have to open a bug in the libssl bugtracker?

[Dan Kegel (dank)]

Can you comment out universe from bionic-updates in /etc/apt/sources.list ?
That works for me, at least for now.

[Boris (kervyn)]

I could, but then I would miss packages like php7.2-fpm or nginx.

[Dan Kegel (dank)]

Can you pin the version of nodejs (either in the command that installs it, or in apt configuration)?

[Boris (kervyn)]

Pinning could be an option. Fixing the problem would be more fun. I hate workarounds

[Dan Streetman (ddstreet)]

I've updated the bug title and description to more accurately reflect the issue. As this isn't a bug in nodejs, i marked it as "invalid", and added openssl1.0 as the target to fix.

[Dan Streetman (ddstreet)]

As an example of some of the packages that conflict with libssl1.0-dev, due to conflict:

$ sudo apt install libssl1.0-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
...<snip out many, many packages>...
Use 'sudo apt autoremove' to remove them.
The following packages will be REMOVED:
  apache2-ssl-dev autobahn-cpp-dev eclipse-titan kpatch-build lcmaps-openssl-interface libace-ssl-dev libboinc-app-dev libbotan1.10-dev libbroccoli-dev libc-client2007e-dev libclamav-dev libclaws-mail-dev libcpprest-dev libdcmtk-dev libdkim-dev libghc-hsopenssl-dev
  libglobus-authz-dev libglobus-ftp-client-dev libglobus-ftp-control-dev libglobus-gass-cache-dev libglobus-gass-copy-dev libglobus-gass-transfer-dev libglobus-gridftp-server-control-dev libglobus-gridftp-server-dev libglobus-gsi-callback-dev
  libglobus-gsi-cert-utils-dev libglobus-gsi-credential-dev libglobus-gsi-openssl-error-dev libglobus-gsi-proxy-core-dev libglobus-gsi-proxy-ssl-dev libglobus-gsi-sysconfig-dev libglobus-gss-assist-dev libglobus-gssapi-error-dev libglobus-gssapi-gsi-dev libglobus-io-dev
  libglobus-openssl-module-dev libglobus-xio-gsi-driver-dev libjose-dev libldns-dev libmongoc-dev libneon27-dev libomniorb4-dev libopkele-dev libp11-dev libpantomime1.2-dev libpbbam-dev libpjproject-dev libpkcs11-helper1-dev libpoco-dev libpodofo-dev libserf-dev
  libshout3-dev libsnmp-dev libspice-client-glib-2.0-dev libssh-dev libssl-dev libssl-ocaml-dev libtorrent-rasterbar-dev libtspi-dev libwebsockets-dev libwinpr2-dev libyara-dev nodeenv nordugrid-arc-dev php7.2-dev proftpd-dev python-chef python3-bitcoinlib
  ubuntu-core-libs-dev urweb uwsgi-dev voms-dev xrdp-pulseaudio-installer znc-dev
The following NEW packages will be installed:
  libssl1.0-dev
0 upgraded, 1 newly installed, 74 to remove and 0 not upgraded.
Need to get 1364 kB of archives.
After this operation, 226 MB disk space will be freed.
Do you want to continue? [Y/n]

[Steve Langasek (vorlon)]

This is expected behavior. These two stacks are incompatible, and while they use symbol versions so will not cause overt ABI problems when loaded into the same namespace, there are still some opaque structures that could be problems when passed between two libraries that each depend on different versions of openssl. So the value of making the -dev packages coinstallable is small from the perspective of the distribution, the costs large given that relocating one or the other library means reverse-dependencies would also need updating to be able to find it at build time, and the risks of anything built against both versions of libssl significant.

[Dan Kegel (dank)]

Then my original bug report was correct. nodejs needs to be updated to a version that uses ubuntu 18.04's openssl instead of using the incompatible one. Shall I refile?

[kapouer (kapouer)]

Le ven. 2 nov. 2018 à 18:41, Steve Langasek <email address hidden>
a écrit :

> This is expected behavior. These two stacks are incompatible, and while
> they use symbol versions so will not cause overt ABI problems when
> loaded into the same namespace, there are still some opaque structures
> that could be problems when passed between two libraries that each
> depend on different versions of openssl. So the value of making the
> -dev packages coinstallable is small from the perspective of the
> distribution, the costs large given that relocating one or the other
> library means reverse-dependencies would also need updating to be able
> to find it at build time, and the risks of anything built against both
> versions of libssl significant.

Hi,

i've just dug into that matter, and here are my conclusions:
- it is quite easy to build and use embedded copy of openssl, and since
Node is doing its own security tracking, it might be a realistic solution
to just do that.
- upstream is developing openssl 1.1.1 compatibility, tests pass on linux,
see https://github.com/nodejs/node/issues/18770, in which case this is
needed to pass tests without heavily patching the test suite:
https://salsa.debian.org/js-team/nodejs/commit/60488253f26c6585a816e292a742fca40afee192
- breaking ABI is now covered by
https://github.com/nodejs/node/blob/master/BUILDING.md#note-for-downstream-distributors-of-nodejs,
so i opened an issue here for debian. I suppose ubuntu could use same
versions: https://github.com/nodejs/TSC/issues/621
- nodejs 10.13 is waiting in NEW/experimental. As soon as it is accepted
i'll backport the work on nodejs 8 branch, in case nodejs 10 doesn't make
it before debian freeze.

Jérémy

[kapouer (kapouer)]

Le ven. 2 nov. 2018 à 19:10, Dan Kegel <email address hidden> a écrit :

> Then my original bug report was correct. nodejs needs to be updated to a
> version that uses ubuntu 18.04's openssl instead of using the
> incompatible one. Shall I refile?
>

There are actually two issues:
- the one you just talked about (using openssl 1.1.1)
- the NODE_MODULE_VERSION advertised by ubuntu or debian does not match the
one provided by upstream, so it needs to be changed.

Jérémy

[Steve Langasek (vorlon)]

On November 2, 2018 11:04:43 AM PDT, Dan Kegel <email address hidden> wrote:
>Then my original bug report was correct. nodejs needs to be updated to
>a
>version that uses ubuntu 18.04's openssl instead of using the
>incompatible one. Shall I refile?

Could you please clarify what it is you're trying to achieve?

If this is about coinstallability of two unrelated stacks of -dev packages, that is not something we are going to make changes in the stable release of Ubuntu in order to support.

If this is about some piece of software requiring both libssl-dev and libssl1.0-dev to be installed at build time due to transitive dependencies, we could reconsider whether to make changes to the packaging to support this for specific situations (i.e., reverting my "wontfix").

We would not do a wholesale update of nodejs in SRU to the version upstream represents is compatible with OpenSSL 1.1; so the status of the bug tasks for that package remains correct.

[Steve Langasek (vorlon)]

On Fri, Nov 02, 2018 at 06:19:54PM -0000, kapouer wrote:
> - the NODE_MODULE_VERSION advertised by ubuntu or debian does not match the
> one provided by upstream, so it needs to be changed.

How do you mean? The previous SRU of nodejs was specifically intended to
address the issue of binary compatibility with upstream.

[kapouer (kapouer)]

Le ven. 2 nov. 2018 à 20:01, Steve Langasek <email address hidden>
a écrit :

> On Fri, Nov 02, 2018 at 06:19:54PM -0000, kapouer wrote:
> > - the NODE_MODULE_VERSION advertised by ubuntu or debian does not match
> the
> > one provided by upstream, so it needs to be changed.
>
> How do you mean? The previous SRU of nodejs was specifically intended to
> address the issue of binary compatibility with upstream.
>

I did mean
 - the NODE_MODULE_VERSION advertised by ubuntu or debian *MIGHT* (unless
special action has been taken otherwise)
not match the one provided by upstream, so it needs to be changed.

Sorry.

[Dan Kegel (dank)]

Here's a short way to see the failure:

1) make sure /etc/apt/sources.list has bionic-updates enabled for universe (and multiverse?)
2) sudo apt update
3) sudo apt install nodejs-dev libssl-dev
...
The following packages have unmet dependencies:
 nodejs-dev : Depends: libssl1.0-dev (>= 1.0.2) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

In other words, the current nodejs-dev does not fit into the Ubuntu 18.04 ecosystem.

[Steve Langasek (vorlon)]

On Fri, Nov 02, 2018 at 08:01:23PM -0000, Dan Kegel wrote:
> The following packages have unmet dependencies:
> nodejs-dev : Depends: libssl1.0-dev (>= 1.0.2) but it is not going to be installed
> E: Unable to correct problems, you have held broken packages.

> In other words, the current nodejs-dev does not fit into the Ubuntu
> 18.04 ecosystem.

I understand that these packages are not coinstallable. That is not per se
a requirement for -dev packages in Ubuntu.

What is your use case for these packages being installed together?

If it's to provide a single host environment where separate software
components build-depending on each of nodejs-dev and libssl-dev can be
built, that is not sufficient rationale for changing the current behavior.
The workaround is for each software component to be built in its own
separate environment with the -dev packages that it requires.

If you have a single software component which you are trying to build, which
is implemented in node and uses libssl, then it should be built against
libssl1.0-dev since that is the version compatible with nodejs-dev in
bionic.

If you have a single software component which is implemented in node and
also must build against another library which depends on libssl-dev, then
and only then should we evaluate changes to the -dev packages to support
this.

In our analysis of the archive for the previous SRU, we did not identify
any packages in the Ubuntu archive which fell into this last category, but
there may be some other software out there which wasn't found in our search.

[Dan Kegel (dank)]

Yup, I have a package that uses node and requires libssl-dev and libcurl-openssl.

It was rather jarring when it stopped building because of the update to node.

If you're saying that Ubuntu is not suitable for developing proprietary software that uses node, libssl, and libcurl, well, I guess that's interesting and surprising news.

[Dan Kegel (dank)]

I've been really happy with Ubuntu for ten years, but this particular situation is making me scratch my head. Might want to get Mark's input here -- is Ubuntu intended to be a
curated ecosystem that works well as a platform for both proprietary and open source software?

[Steve Langasek (vorlon)]

On Fri, Nov 02, 2018 at 09:19:56PM -0000, Dan Kegel wrote:
> Yup, I have a package that uses node and requires libssl-dev and
> libcurl-openssl.

Ok, thanks for clarifying.

But there is a build of libcurl-openssl linked against libssl1.0 in 18.04,
and therefore compatible with nodejs (libcurl-openssl1.0-dev).

And if you are using libssl directly, then you should use the one that's
compatible with the other libraries that you depend on (in this case:
libssl1.0-dev which would be compatible with nodejs-dev). You wouldn't be
able to take advantage of newer features from OpenSSL 1.1, but that is the
tradeoff of using nodejs packages from an Ubuntu release before OpenSSL 1.1
support is complete.

Does the above configuration meet your needs for a coherently installable
set of build dependencies, or are there other ssl-depending Ubuntu library
packages in the mix besides?

[Dan Kegel (dank)]

Our project also links against libssh-dev (sorry, I meant to mention that),
which has the same problem, but lacks a libssh-openssl1.0-dev.

Also, it's somewhat jarring to have to change dependency names
when we build against ubuntu 18.04 vs. 16.04; we can do that,
and have done it, but it adds a layer of confusion.

Giving up on Ubuntu's node seems like the best option at the moment,
which makes me sad. But since the next version of node uses the 'right'
version of openssl for ubuntu 18.04, it's very very tempting to
grab that from debian and slam it in to our 18.04 under a different name
(as we did with nodejs6 for a while).

I'm fighting a rising tide of "just use docker and upstream everything",
so if you don't hear from me anymore, I may have drowned :-)

[Steve Langasek (vorlon)]

On Fri, Nov 02, 2018 at 11:51:20PM -0000, Dan Kegel wrote:
> Our project also links against libssh-dev (sorry, I meant to mention that),
> which has the same problem, but lacks a libssh-openssl1.0-dev.

Ok. But it does have a libssh-gcrypt-dev, is there any chance this meets
your needs?

[Dan Kegel (dank)]

{Thank,curse} you for offering that solution. I will have a look!

[Dan Kegel (dank)]

The next place this reared its ugly head was libxmltooling7 / libxml-security-c-dev, and I don't see an alternate available.

Looks like ubuntu 18.10 has solved that bit. Maybe the answer for me is to give up on 18.04 and use 18.10 / 19.04 / 19.10 / 20.04. I really don't think our product folks would like that, though; we much prefer LTS.

I suppose libxmltooling7 / libxml-security-c-dev / etc. could be backported from 18.10, with a different -dev package name, so that desperate people could get things building by changing -dev packages. I wonder how much of the sweater that would unravel....

[Dan Kegel (dank)]

Those two weren't hard; I also had to backport opensaml2-tools. I can imagine a little ppa with those three packages and maybe a few more; using the ppa would let you rebuild your app using the backported packages (and prevent you from building against the old packages, as the new -dev's would overwrite the standard ones).

I'll keep slogging. At some point I'll try libssh-gcrypt-dev et al, haven't gotten to that yet.

[Dan Kegel (dank)]

I uploaded the backports of xmltooling, xml-security-c, and opensaml2 to https://launchpad.net/~dank/+archive/ubuntu/openssl-uplift
and wrote it up at http://kegel.com/linux/openssl-ubuntu18.04-snafu/

That might be enough to let us limp by now that we've given up on the nodejs packaged with ubuntu.

[Jani Jaakkola (jj-lousa)]

I am maintaining Ubuntu installations here at University of Helsinki, where I try to provide a single environment for as many users as possible, where the students and researchers are also developers, and can't always be given administrator rights. Our students need nodejs for their studies, but the same students need libssl-dev for other software. On the same Ubuntu installations. So I have a use case where I can't just switch package collections based on what is needed just right now. Since I need a fix for this by Monday, I need to figure out a way around this, but I'd appreciate if "just change your package collection" would not be considered as an adequate solution to this kind of problem in the future.

[Jani Jaakkola (jj-lousa)]

I fixed this by installing the newer nodejs version from upstream, which is better for our students anyway. Sorry about the rant.

[Dan Kegel (dank)]

That was the correct solution, and I sympathise with your rant.

Node is an ecosystem, and shipping a version of node that can't handle native libraries is like sticking a fork in the eyes of the users.

[kenjo (ken-kenjo)]

I hit this too and If I understand this correctly the only way out is now to install a custom version of nodejs and npm as both packages forces install of libssl1.0-dev and I can not allow that package in as it breaks other builds.

:( really nasty error this one. fails on 18.04 and 18.10.

any pointers to backport ppa or do I have to make this myself ?

[Dan Kegel (dank)]

You could try https://github.com/nodesource/distributions/blob/master/README.md

[Dan Kegel (dank)]

I just re-read kapouer's comments. They seem spot on.

I also re-read vorlon's comments. They have a vaguely disturbing attitude along the lines of 'Why are you using Ubuntu to develop software on? It's only for running software somebody else built already.'

[Dan Kegel (dank)]

In hopes of being able to create a ppa that reduces the pain level a bit, I tried rebuilding a newer nodejs for ubuntu 18.04 using the debian/ubuntu nodejs git repo.

Using the source from 19.04's runs into quite a few test failures ( https://github.com/nodejs/help/issues/1760 ).

debian/10.4.0_dfsg-2 has a few test failures ( https://github.com/nodejs/help/issues/1767 ), but seems promising. Unfortunately, I'm not familiar with nodejs debian packaging, and I'm a bit mystified by the test-assert failure. Where's the best place to discuss a backport like that?

[kapouer (kapouer)]

Le mer. 13 févr. 2019 à 18:55, Dan Kegel <email address hidden> a écrit :

> In hopes of being able to create a ppa that reduces the pain level a
> bit, I tried rebuilding a newer nodejs for ubuntu 18.04 using the
> debian/ubuntu nodejs git repo.
>
> Using the source from 19.04's runs into quite a few test failures (
> https://github.com/nodejs/help/issues/1760 ).
>
> debian/10.4.0_dfsg-2 has a few test failures (
> https://github.com/nodejs/help/issues/1767 ), but seems promising.
> Unfortunately, I'm not familiar with nodejs debian packaging, and I'm a
> bit mystified by the test-assert failure. Where's the best place to
> discuss a backport like that?
>

Hello Dan,

i could help if you asked me precise questions.

Jérémy

[David (dskloet)]

Steve Langasek, when you wrote

> The workaround is for each software component to be built in its own
> separate environment with the -dev packages that it requires.

what did you mean by "separate environment"?
Do I have to buy a separate computer to use nodejs, or is there some way to have multiple of these "environments" in the same Ubuntu installation?

[Dan Kegel (dank)]

I think the advice is harder to follow than it looks. Many node packages require libssl-1.0-dev,
and you can't install them on a system used to develop c/c++ apps that require libssl-dev.
To wit:

$ sudo apt install -s node-websocket libssl-dev
...
 node-websocket : Depends: nodejs-dev (>= 8.9.3~dfsg-11ubuntu1~) but it is not going to be installed
                  Depends: libjs-websocket but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

So it's more like "you can't count on being able to use xenial's nodejs on any system that
has to build stuff against libssl-dev", which is pretty traumatic.

The situation's better on cosmic. Backporting cosmic's nodejs to xenial isn't a great fix,
though, because it has a different soname, so any packages that need node's shared library
have to be rebuilt. And that breaks our user apps. As a workaround I'm using upstream's nodejs 8 on xenial, that seems to sidestep the openssl problem without causing the major version number problem.

[Steve Langasek (vorlon)]

On Sun, Feb 24, 2019 at 10:26:54PM -0000, David wrote:
> Steve Langasek, when you wrote

> > The workaround is for each software component to be built in its own
> > separate environment with the -dev packages that it requires.

> what did you mean by "separate environment"?

> Do I have to buy a separate computer to use nodejs, or is there some way
> to have multiple of these "environments" in the same Ubuntu installation?

Modern Linux supports many different methods of virtualization. You can use
chroots for building, which you might manage using the schroot package; or
you can use lxd containers.

[Dan Kegel (dank)]

Even with lxd or schroot, you won't be able build anything against libssl-dev if your build script happens to need any of the nodejs modules that use openssl.
So that's not really much of a workaround.

[hakon (hakon-hagland)]

I was able to install the nodejs package (8.11.4~dfsg-0ubuntu1)

https://packages.ubuntu.com/cosmic/nodejs

on Ubuntu 18.10 with "sudo apt-get install nodejs", but when I tried to install
npm (5.8.0+ds-2)

https://packages.ubuntu.com/cosmic/npm

It failed due to nodejs-dev depending on libssl1.0-dev. I solved this issue by installing npm with the install script at:

https://github.com/npm/cli

That is, I used the following command:

curl -L https://www.npmjs.com/install.sh | sudo sh

[Dimitri John Ledkov (xnox)]

nodejs 8.x series uses libssl1.0-dev (OpenSSL 1.0.2) across all linux distributions and upstream.

nodejs 10.x series uses libssl-dev (OpenSSL 1.1.0+) across all linux distributions and upstream.

libssl1.0-dev and libssl-dev are intentionally non-coinstallable, as they both own the same include headers and the libssl.so/libcrypto.so symlink.

If you are using nodejs 8.x you do want to build with libssl1.0-dev, ideally in a chroot / container.

If you are using nodejs 10.x you do want to build with libssl-dev (>= 1.1.0), ideally in a chroot / container.

Thus everything is setup, intentially, correct to enforce correct openssl ABIs.

[Dimitri John Ledkov (xnox)]

I see that people who use nodeenv potentially can get trapped, because of:

$ apt show nodeenv | grep -e Package -e Depends
Package: nodeenv
Depends: python3-pkg-resources, python3, python3:any (>= 3.3.2-2~), make, gcc (>= 4:4.9.1) | nodejs, g++ (>= 4:4.9.1) | nodejs, libssl-dev | nodejs, python2.7 | nodejs

note the bogus "libssl-dev | nodejs" which is quite bad.

[Dan Kegel (dank)]

It's worse than that. Developers who use nodejs in their apps, and have to use libssl-dev, are simply screwed. Even moving to a container won't help.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[RedScourge (redscourge)]

While not relevant to nodejs, I'll add an anecdote that I was trying to build older versions of php via phpbrew on 18.04 for development purposes, and ran into a similar issue due to this libssl1.0-dev vs libssl1.1-dev issue.
The issue is that seemingly some of the -dev libraries required to build various php modules use different versions of ssl, and so if you choose to build one, you cannot build the other, unless you take some convoluted path involving downloading source and compiling half the known universe, or simply not using certain php modules entirely. I did not encounter this same difficulty on 16.04 LTS as it seems that more of the -dev packages were built against 1.0.

Obviously I would not expect Ubuntu to support building versions of php which are no longer in support, but I just wanted to mention that this libssl-dev thing may cause lots of other issues in rarer use cases. Too bad the openssl team did not have a better option to facilitate backward compatibility between these versions.

[Dan Kegel (dank)]

Yeah... I suspect the OpenSSL folks are painfully aware of that, and future versions will likely be much better at preserving compatibility.

[elatllat (elatllat)]

Trying to build https://github.com/mit-pdos/noria without removing node.js.... Ubuntu 18.04 needs to fix it's node.js package.

[bp-art (bp-art)]

Affects me too. We are having to (re-)package our own version of nodejs-dev with depend on libssl-dev instead of libssl1.0-dev in order to use nodejs without uninstalling hundreds of other debian package on an 18.04 system.

Surprised this is still open over a year after reporting.

[Jure Sah (dustwolfy)]

Still happens on 18.04 , nodejs.

[Dimitri John Ledkov (xnox)]

Default implementation of openssl in bionic is 1.1.1.
There is a small amount of packages that uses openssl1.0 at runtime in bionic, because packages in question did not migrate to 1.1.1 in time for bionic release.
It is not possible to co-install openssl 1.1.1 & 1.0 development headers and there is nothing that Ubuntu can do to fix that.
nodejs was explicitely set to use openssl1.0 in bionic.
Note that switching development headers from 1.1.1 & 1.0 is relatively painless and easy, and it should not result in any runtime libraries being removed or switched around.

[Dan Kegel (dank)]

Well, yes. And as a result, the nodejs package on bionic is completely broken
when you actually try to use it for any project.

So, I guess one should avoid bionic if one uses nodejs?

[Henk Poley (henkpoley)]

Would it be possible to pick one openssl version and statically compile the ones that use other, or have some simple tool that helps you point a build process to the required version ?

e.g. that the libssl package tries *less* to be a seamless upgrade, when it is not a seamless upgrade either way. Separate it more, so at least you can have them side by side.

[Dan Kegel (dank)]

No, it's hard to imagine that working, I fear.

Theoretically Canonical could upgrade bionic's nodejs to use the system's primary openssl.
That is also not likely to happen, though, as it is a lot of work, and still might not please nodejs users fully. (Plus it could break some users.)

[MasterCATZ (mastercatz)]

another day wasted trying to work out why things were not running on Ubuntu 20.04 and its because of libssl1.0-dev needed which conflicts with libssl-dev ...

[Kuba Suder (mackuba)]

I have the same problem (bionic):

- aptitude is showing 2 uninstalled updates, libmysqlclient-dev and libmysqlclient20
- I can't update them, because they require libssl-dev
- if I decide to install libssl-dev, I need to uninstall libssl1.0-dev
- if I do that, I would need to remove nodejs-dev which requires libssl1.0-dev

As I understand, all of the packages listed above come from the Ubuntu repository (universe) - since this is an LTS release, shouldn't it be kept in a state where it's always possible to install two unrelated packages (here: libmysqlclient and nodejs) and they don't conflict with each other?

[Robie Basak (racb)]

> Theoretically Canonical could upgrade bionic's nodejs to use the system's primary openssl.

This isn't possible. It would resurface bug 1779863. The nodejs version in Ubuntu Bionic requires a specific version of OpenSSL to remain compatible with external third party modules, since the version of OpenSSL used forms part of its ABI. Details in the other bug.

> As I understand, all of the packages listed above come from the Ubuntu repository (universe) - since this is an LTS release, shouldn't it be kept in a state where it's always possible to install two unrelated packages (here: libmysqlclient and nodejs) and they don't conflict with each other?

Ideally, yes, but due to the way Node upstream works (or at least, the way it did work at the time of the Node version in Bionic), this restriction exists.