Martin Pitt wrote: > Ludwig Nussel [2020-09-25 19:49 +0200]: > [...] >>> 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.
Well, openSUSE does. We do fully transitive 11k package rebuilds all the time :-) Any package that does not build automatically after wiping all binaries sucks. Gcc and binutils aren't injected binaries that fell off the sky either. They are part of a base bootstrap cycle that OBS rebuilds automatically too. There are some prominent and hard to fix cases like Rust but that is the exception. Cockpit with sass does not qualify for such an exception :-) > 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, For cockpit to actually build in openSUSE we cannot include the sass binary, it has to build from source: https://en.opensuse.org/openSUSE:Packaging_guidelines#General_guidelines >> 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). What I have so far does not introduce any new package. Just a thousand extra tarballs next to the spec file :-) Those can be managed automatically. The checksum file the tool produces is the same format as the 'sources' file in Fedora. The patches required for gyp and sass should really go upstream. With that you could even call the tool in your CI and export the three text files¹ it produces somewhow. Should be really easy to package and rebuild any given git hash then. cu Ludwig [1] spec file snippet, tarball->node_modules/ location and checksums ie 'sources' file -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.com/ SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer HRB 36809 (AG Nürnberg) _______________________________________________ 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]
