Hello, I have recently (last week) taken on maintenance of several to-be orphaned nodejs packages. Since the packages were not upgraded for a while, they are usually a major version behind the upstream release. I have started to remedy this, but given the relatively large jump in version numbers, there might be issues. If your node package stops building in rawhide suddenly, check the dependencies for updates; feel free to reach to me with related issues.
The upgraded (or soon to be upgraded) packages in question: - nodejs-bluebird - nodejs-clean-css - nodejs-grunt-known-options - nodejs-path-exists
Keep in mind that the above list might expand in the near future, given the current situation with many nodejs-* orphans.
On Mon, Apr 29, 2019 at 7:49 AM Jan Staněk jstanek@redhat.com wrote:
Hello, I have recently (last week) taken on maintenance of several to-be orphaned nodejs packages. Since the packages were not upgraded for a while, they are usually a major version behind the upstream release. I have started to remedy this, but given the relatively large jump in version numbers, there might be issues.
One of the frustrating things with NodeJS packaging in Fedora is that because of the crazy number of dependencies between NodeJS packages, a simple version bump in one package could cause a whole cascade of other packages that need to be updated to newer versions to support that dependency here.
The right thing to do in this case is to look at each of those packages, find anything that's dependent upon those packages, and make sure each one will still work with the newer version of the package. It's tiresome, thankless work -- and you often end up getting three or four levels down the dependency tree before realizing things aren't going to work -- which is why I've stepped away from packaging up new NodeJS packages for a while...
-- Jared Smith
On 29. 04. 19 15:42, Jared K. Smith wrote:
One of the frustrating things with NodeJS packaging in Fedora is that because of the crazy number of dependencies between NodeJS packages, a simple version bump in one package could cause a whole cascade of other packages that need to be updated to newer versions to support that dependency here.
That's why I'm only doing this in Rawhide (and I would love to have something akin to Rawhide-testing).
The right thing to do in this case is to look at each of those packages, find anything that's dependent upon those packages, and make sure each one will still work with the newer version of the package.
That will never work (long-term) without the cooperation with the maintainers of the affected packages. I'm happy to help with any issues caused by the update, but I would leave finding these issues to koschei.
Only other option I can think of is going the Rust route (packages only in rawhide, anything depending on them must be a module), which I'm not a fan of.
Best regards,
On 29/04/2019 15:21, Jan Staněk wrote:
Only other option I can think of is going the Rust route (packages only in rawhide, anything depending on them must be a module), which I'm not a fan of.
Module don't work for Node.js though.
They work for rust and go because of static linking, so different packages can pull in the library versions (from parallel available modules) at build time and then those libraries are statically linked into the resulting program.
Node.js is totally different though - there the node modules are needed at run time by the installed packages not just at build time so you would need parallel installability not just availability.
Tom
On 2019-04-29 10:31 a.m., Tom Hughes wrote:
On 29/04/2019 15:21, Jan Staněk wrote:
Only other option I can think of is going the Rust route (packages only in rawhide, anything depending on them must be a module), which I'm not a fan of.
Module don't work for Node.js though.
They work for rust and go because of static linking, so different packages can pull in the library versions (from parallel available modules) at build time and then those libraries are statically linked into the resulting program.
Node.js is totally different though - there the node modules are needed at run time by the installed packages not just at build time so you would need parallel installability not just availability.
Right. For major versions the only way is to resort to the good olde versioned packages.
nodejs-xxx for the latest and nodejs-xxxN for the legacy one needed
In the case of node I wonder if all packages should not be versioned with the major version anyway.
Besides that, we'd have to relax dependencies with '^' around. But to do that we'd need to have some basic tests for the modules we meddle with the dependencies.
Fernando
Tom
-
Fernando Nasser -
Jan Staněk -
Jared K. Smith -
Tom Hughes