[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Potential removal of unmaintained node-openzwave-shared
From: |
Philip McGrath |
Subject: |
Re: Potential removal of unmaintained node-openzwave-shared |
Date: |
Sat, 25 Mar 2023 12:58:31 -0400 |
User-agent: |
Cyrus-JMAP/3.9.0-alpha0-236-g06c0f70e43-fm-20230313.001-g06c0f70e |
Hi,
On Wed, Mar 22, 2023, at 8:08 AM, Jelle Licht wrote:
> Hey guix,
>
> In getting `Node.js' updated to a more recent LTS version[0], I found
> out that node-openzwave-shared no longer builds with modern versions of
> node [1]; random people on the Internet seem to indicate that
> the hip new thing is Z-Wave JS [2].
>
> Long story short, what is our de facto policy here?
>
> 1) Keep around a copy of Node 14 and all node-openzwave-shared deps,
> even after the End Of Life of 2023-04-30
> 2) Remove node-openzwave-shared, and move to Node 18 whenever possible
> without this package.
> 3) Patch node-openzwave-shared' so it builds with newer versions of
> Node, and move to Node 18.
> 4) Remove node-openzwave-shared, move to Node 18, package the relevant
> parts of Z-Wave JS.
>
> I don't have the time nor means for anything but option 2) myself, so if
> consensus deems any of the other options a better way forward,
> volunteers are invited to apply :-)
>
> [0]: https://issues.guix.gnu.org/59188
> [1]: https://github.com/OpenZWave/node-openzwave-shared/issues/398
> [2]: https://github.com/zwave-js?type=source
I added this package, so I have some interest in trying options 3 or 4, but I
don't think this should block Node 18 in any case.
Is there a log message for the build failure somewhere? I don't see any details
at [2], and I'm a bit surprised by the failure.
It's true that open-zwave and, by extension, node-openzwave-shared currently
have no active maintainers. On the other hand, AIUI, it still works fine, and
e.g. Debian Bookworm still has libopenzwave1.6 packaged: my impression is that
the only changes in several years, even before the loss of maintainers, have
been adding XML definitions for new hardware.
On the other hand, while I've heard good things about Z-Wave JS and on
principle would favor a memory-safe language, the large number of NPM
dependencies seem likely to make it difficult to package. (The person who
recommended it in [2] is one of its maintainers, FYI.)
-Philip