https://bugzilla.redhat.com/show_bug.cgi?id=1969450 --- Comment #11 from Ben Beasley <code@xxxxxxxxxxxxxxxxxx> --- > This sounds strange -- all of the js code is being run by a remote browser, not by node.js. So it may not make a practical difference, but it's still conceptually wrong IMHO. This is *not* a node.js package/library. I agree it’s conceptually wrong, but I’m not aware of a way to express build architecture restrictions separately from runtime architecture restrictions. The problem is that a noarch package may be assigned to a koji builder of any architecture. If a noarch package has ExclusiveArch/ExcludeArch BR’s, the build will fail due to missing dependencies on builders of the “wrong” architectures. It’s possible to ignore this and just hope the build is eventually re-tried on an acceptable architecture, although there’s no guarantee that will happen in a particular bounded number of tries. It’s a mostly-academic quandary given that “rpm -E %nodejs_arches” currently gives > i386 i486 i586 i686 pentium3 pentium4 athlon geode x86_64 armv3l armv4b armv4l armv4tl armv5tl armv5tel armv5tejl armv6l armv6hl armv7l armv7hl armv7hnl armv8l armv8hl armv8hnl armv8hcnl aarch64 ppc64 ppc64p7 ppc64le s390x which covers all Fedora primary architectures. This point certainly remains open to discussion. ----- > The guide says "included" -- it is included in the srpm, but certainly not in the binary rpm. That's exactly how every other language works, too -- we don't include C/Java/Rust sources into binary packages as well. > The other paragraphs are indeed aimed at actual node-* libraries, it seems - but this isn't one. I’m going to keep arguing for my original interpretation here. The guidelines in https://docs.fedoraproject.org/en-US/packaging-guidelines/JavaScript/#_compilationminification allow compilation/minification specifically for JavaScript that is intended for the web, and otherwise prohibits it. So discussion of compilation/minification does apply here. The first paragraph says that: > If a JavaScript library typically is shipped as minified or compiled code, it MUST be compiled or minified as part of the RPM build process. This already means that the sources must be in the source RPM. The third paragraph says: > Additionally, the uncompiled/unminified version MUST be included alongside the compiled/minified version. This is clearly intended to be an additional restriction, not a restatement of the first paragraph, and to me it seems clear that “included alongside” refers to the installation. There’s certainly no requirement for the two versions to be “alongside” each other in the source RPM; on the contrary, the pre-minified versions must be removed in %prep if present. I think this guideline reflects a somewhat obsolete understanding that JavaScript sources are directly usable without further processing, and compiling or minification is only an optimization for the web. Under that understanding, this guideline could be compared to the requirement for Python packages to contain .py files and not just .pyc CPython bytecode files. I agree with you that, today, JavaScript is treated like machine code even when the original sources are also JavaScript, and these guidelines are making less and less sense. Still, at the moment, I still read them as requiring the original JavaScript sources to be installed, even if this is relatively useless to the package’s users. ---- > Sent a fix upstream in https://github.com/cockpit-project/cockpit/pull/16361 , will land in Fedora in two weeks. Thanks! This sounds like the correct solution to me. ---- I appreciate your hard work and reasonable dialogue toward making this package work. It’s not an easy one, but I think it’s viable. -- You are receiving this mail because: You are on the CC list for the bug. You are always notified about changes to this product and component https://bugzilla.redhat.com/show_bug.cgi?id=1969450 _______________________________________________ package-review mailing list -- package-review@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to package-review-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/package-review@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
