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