Hello Ludwig, Ludwig Nussel [2020-09-25 13:25 +0200]: > So far the cockpit packages we have for openSUSE Tumbleweed use the > upstream release tarball. That means all web assets are prebuilt.
Right, that's how we use them as well. > Therefore cannot be patched, it's almost like bundling binaries. Indeed we avoid that -- what we do for RHEL is to have stable branches like https://github.com/cockpit-project/cockpit/tree/rhel-8.3 to which we backport fixes -- then they can benefit from the full CI machinery, and get landed with confidence. At an appropriate time we then can just `make dist`, or even tag them. We actually did try applying patches in the past, but it was such a mess and we could never be confident that everything *really* worked. > In openSUSE a package build is fully unattended, automatic and has > no network access. FTR, that's the same in Fedora/RHEL/Debian/Ubuntu. > That means all that nodejs stuff needs to be available. When talking to other > developers that touched Nodejs before, they just recommended to tar up > node_modules/. That's not acceptable either IMO as it also would be just some > magic tarball that we don't really know how it was created. It's not any more magic than building the main release tarball -- on https://github.com/cockpit-project/cockpit/releases we publish the cockpit-cache-VERSION.tar.xz tarballs, so you *could* just include them into your source distribution packages and use them to build. > So I wrote a PoC tool that parses package-lock.json instead. With > that information we know what upstream nodejs modules npm decided to > use and where to put them in node_modules/. Note that `npm install` does exactly that already -- If a package-lock.json is present, it will reproduce the exact versions. That's why we include package-lock.json into our release tarballs, so that in situations with internet access the entire build is reproducible. `npm install` also does not re-download already existing packages. However, it is still not fully offline, as it will always check the npmjs.com package index despite package-lock.json. Maybe that can be avoided somehow -- but in such a case, just grabbing cockpit-cache*.tar.xz seems much easier? > https://build.opensuse.org/package/show/home:lnussel:branches:systemsmanagement:cockpit:rebuild/cockpit > > The madness comes from the huge amount of tarballs. Apart from that > looks quite straight forward, doesn't it? :-) Heh, yes -- in spirit that's kind of an npmjs.com mirror. Are you afraid of license problems in the case npmjs.com is going down? I can see the need for keeping all the original sources at the same downstream location. (Again, cockpit-cache* seems easier to me, but this is certainly a valid approach). > Also, cockpit-podman wants to use bits of cockpit > (pkg/lib/patternfly) and the Makefile gets that from git if not > present. Right, but that's just for upstream git. The `make dist-gzip` rule explicitly includes these files, so the are part of the released tarballs (I just validated cockpit-podman-23.tar.gz). > So I had to create a cockpit-devel subpackage that can be consumed by > cockpit-podman. Would that be something to consider for upstream too? Ie > install those files and probably a pkgconfig file in cockpit, then check for > that in the Makefiles of modules? Honestly, I find our current approach of checking out a validated tag so much simpler to maintain. For upstream developing against git you absolutely need internet, and for building packages out of release tarballs it will only complicate the packaging a lot. We really don't give *any* API guarantees about these, and these files are not at all a product. Thanks for looking into this! These are questions that keep coming up in distributions indeed, I've had my fair share of them. Pitti _______________________________________________ cockpit-devel mailing list -- [email protected] To unsubscribe send an email to [email protected] 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.fedorahosted.org/archives/list/[email protected]
