Bug#1002035: nodejs: sse2-support failure leaves dependencies in apt that cannot be met

[J. William Campbell]

Package: nodejs
Version: 12.22.5~dfsg-2~11u1
Severity: important
X-Debbugs-Cc: jwilliam...@comcast.net

Dear Maintainer,

I attempted to install package nodejs on an Intel processor that does not
support sse2 instructions. The library dependencies for nodejs require
the sse2 support. It is unclear to me why nodejs itself would require
such support, but in any case installing nodejs requires package
sse2-support, which will always fail to install on older CPUs. This in
itself, while disappointing, isn't a problem. However, this failure occurs
fairly deep in the installation of packages. The result a package with
dependencies that cannot be statisfied. --fix-broken is of course unable to
do so, because sse2-support will never install.

I now have a broken apt configuration that I have been unable to fix. I
cannot remove/purge nodejs because of the unmet dependencies and I
cannot meet them because the required package will not ever install.

This is a serious annoyance. The package sse2-support is present only to
cause the install of the package to fail. It provides no code. A possible
fix would be to allow the user to force sse2-support to install in order to
satisfy the dependencies so that the package nodejs will not be broken.
The user can then remove nodejs or go ahead with the understanding that if
sse2 instructions in the library are actually used a fault will occur. The
documentation does not warn that nodejs requires sse2-support, but even
if it did it is probable this fact would be unclear to many users.

What I expected is that nodejs would install without problems, and that
if it did not it would not leave the package management on my Debian
system basically inoperative. That is where I am now, and I have been unable
to find a solution.

-- System Information:
Debian Release: 11.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: i386 (i686)

Kernel: Linux 5.10.0-9-686 (SMP w/1 CPU thread)
Locale: LANG=C, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages nodejs depends on:
ii libc6 2.31-13+deb11u2
iu libnode72 12.22.5~dfsg-2~11u1

Versions of packages nodejs recommends:
ii ca-certificates 20210119
ii nodejs-doc 12.22.5~dfsg-2~11u1

Versions of packages nodejs suggests:
pn npm <none>

-- no debconf information

[Jérémy Lal]

hello,

NB: i am going to reply below, in chronological order.

Please adopt the same style in future emails.

Le lun. 20 déc. 2021 à 19:48, J. William Campbell <jwilliam...@comcast.net> a écrit :

Package: nodejs
Version: 12.22.5~dfsg-2~11u1
Severity: important
X-Debbugs-Cc: jwilliam...@comcast.net

Dear Maintainer,

I attempted to install package nodejs on an Intel processor that does not
support sse2 instructions. The library dependencies for nodejs require
the sse2 support. It is unclear to me why nodejs itself would require
such support, but in any case installing nodejs requires package
sse2-support, which will always fail to install on older CPUs. This in
itself, while disappointing, isn't a problem.

Indeed, nodejs embeds another software (v8) that needs a lot of

work for each architecture. Authors of v8 decided to simplify their

work by supporting only a subset of available processors.

To make sure, you can double-check that nodejs as distributed by

their authors, does indeed *not* run on your system, by trying their

own debian package, see instructions at:

https://github.com/nodesource/distributions

However, this failure occurs
fairly deep in the installation of packages. The result a package with
dependencies that cannot be statisfied. --fix-broken is of course unable to
do so, because sse2-support will never install.

Yes, you cannot install sse2-support  on a system that doesn't support sse2.

This is by design.

I now have a broken apt configuration that I have been unable to fix. I
cannot remove/purge nodejs because of the unmet dependencies and I
cannot meet them because the required package will not ever install.

I'm not sure that you have a problem with nodejs debian package here.

It looks, from the description of your problem, that you don't know how to

deal with apt in that case. 

You should seek some help on that front.

This is a serious annoyance. The package sse2-support is present only to
cause the install of the package to fail. It provides no code. A possible
fix would be to allow the user to force sse2-support to install in order to
satisfy the dependencies so that the package nodejs will not be broken.
The user can then remove nodejs or go ahead with the understanding that if
sse2 instructions in the library are actually used a fault will occur. The
documentation does not warn that nodejs requires sse2-support, but even
if it did it is probable this fact would be unclear to many users.

What I expected is that nodejs would install without problems, and that
if it did not it would not leave the package management on my Debian
system basically inoperative. That is where I am now, and I have been unable
to find a solution.

I repeat here: on a i686 non-sse2 platform, you can't install nodejs.

However, i hear you, there should be a more explicit way of failing installation

of a package that is not available for a given processor.

Jérémy

[Jérémy Lal]

Le lun. 20 déc. 2021 à 21:11, J. William Campbell <jwilliam...@comcast.net> a écrit :

Hi Jérémy,

       Thank you for your very prompt reply. I will reply in line to your responses.

On 12/20/2021 11:14 AM, Jérémy Lal wrote:

hello,

NB: i am going to reply below, in chronological order.

Please adopt the same style in future emails.

Le lun. 20 déc. 2021 à 19:48, J. William Campbell <jwilliam...@comcast.net> a écrit :

Package: nodejs
Version: 12.22.5~dfsg-2~11u1
Severity: important
X-Debbugs-Cc: jwilliam...@comcast.net

Dear Maintainer,

I attempted to install package nodejs on an Intel processor that does not
support sse2 instructions. The library dependencies for nodejs require
the sse2 support. It is unclear to me why nodejs itself would require
such support, but in any case installing nodejs requires package
sse2-support, which will always fail to install on older CPUs. This in
itself, while disappointing, isn't a problem.

Indeed, nodejs embeds another software (v8) that needs a lot of

work for each architecture. Authors of v8 decided to simplify their

work by supporting only a subset of available processors.

To make sure, you can double-check that nodejs as distributed by

their authors, does indeed *not* run on your system, by trying their

own debian package, see instructions at:

https://github.com/nodesource/distributions

However, this failure occurs
fairly deep in the installation of packages. The result a package with
dependencies that cannot be statisfied. --fix-broken is of course unable to
do so, because sse2-support will never install.

Yes, you cannot install sse2-support  on a system that doesn't support sse2.

This is by design.

Indeed it is by design. However, that design has serious drawbacks 😁.

I now have a broken apt configuration that I have been unable to fix. I
cannot remove/purge nodejs because of the unmet dependencies and I
cannot meet them because the required package will not ever install.

I'm not sure that you have a problem with nodejs debian package here.

It looks, from the description of your problem, that you don't know how to

deal with apt in that case. 

You should seek some help on that front.

I have, at least in so far as lots of Google searches. Basically, I have got nowhere. The "normal" way to correct missing dependencies is to find a package that satisfies those dependencies and install it. This approach works even when your intention is to subsequently purge the package that caused the problem in the first place, but ONLY if you find and install such a package. Since sse2-support is designed to not install in this case, you can't ever do so. There are lots of attempts to solve similar problems by various combinations of approaches. None of them seem to work in this case. If you have a pointer to a method that will reliably remove packages with unmet dependencies, I would appreciate it.

This is a serious annoyance. The package sse2-support is present only to
cause the install of the package to fail. It provides no code. A possible
fix would be to allow the user to force sse2-support to install in order to
satisfy the dependencies so that the package nodejs will not be broken.
The user can then remove nodejs or go ahead with the understanding that if
sse2 instructions in the library are actually used a fault will occur. The
documentation does not warn that nodejs requires sse2-support, but even
if it did it is probable this fact would be unclear to many users.

What I expected is that nodejs would install without problems, and that
if it did not it would not leave the package management on my Debian
system basically inoperative. That is where I am now, and I have been unable
to find a solution.

I repeat here: on a i686 non-sse2 platform, you can't install nodejs.

However, i hear you, there should be a more explicit way of failing installation

of a package that is not available for a given processor.

Indeed. Right now sse2-support pops up a failure screen informing you that your processor doesn't support the required instructions and returns an error code indicating the package was not installed. IMHO a better approach would be to throw the error but allow the user to proceed anyway (return a "success" code) by responding to a prompt. The user has been told the software won't work, so he has no right to expect it will. However, if the package is installed one can remove nodejs without problems. I understand that it might be real hard to "walk back" all the things that were already installed before the problem was detected. For that reason, a "work around" would be appropriate.

Now i think the problem you see comes from sse2-support package.

That bad a user experience is probably a bug somewhere.

Let's see what their maintainer think about it (cc-ing them).

Jérémy