Hello Ludwig, Ludwig Nussel [2020-09-25 19:49 +0200]: > Also, some products that could be candidates to have cockpit > included may still be in use when our names are long engraved on > tombstones already. So while using an additional, external CI system > to feed the actual distro build system works today, the workflow should > be prepared to work without. So plain old src.rpm should work for > rebuilding within the distro. Whether or not the poor souls that have to > do that in the future care about a bundle approach like cockpit-cache or > original sources I don't know. To me the pristine sources way looks like > the cleaner one, even if that means more effort to set up :-)
Heh, interesting perspective -- honestly, without running the CI somewhere, one can't have much trust in Cockpit's functionality. We find regressions in various operating systems literally every week. But of course, my comments were in no way meant to stop you! I just tried to explain the status quo in Fedora/Debian, as there we as upstream maintainers are the same persons who do the downstream maintenance as well. > > 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. > > That's also just the node_modules directory. It does not contain > pristine upstream sources. That tree likely even contains binaries. > Probably ones that you didn't build yourself. IIRC it is sass that > tries hard use a binary downloaded from github for example. Yes, that's correct -- it's the node_modules directory only. I think that's fair enough -- nobody expects a fully transitive build from scratch for *any* disto package, that would be hilariously expensive and just practically impossible. "sass" is just the moral equivalent of gcc or binutils here. Of course the difference is that gcc or binutils are properly packaged in distros and themselves are built from source, which isn't true for e.g. sass. So if your efforts are about properly packaging compiled devDependencies, then that's a very laudable approach. There aren't too many of these, > That's fine. Part of the exercise is building from a git tag resp master > rather than the release tarball. That'd be a great achievement indeed! The entire npm packaging philosophy, build tools, etc. make this rather hard, and we shyed away from even attempting that. If you manage to get that working, I'm certainly interested in adopting that approach for Debian/Fedora as well (if it isn't too expensive and needs introducing a lot of new packages). Thanks, Martin _______________________________________________ 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]
