Martin Pitt wrote:
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
fixes -- then they can benefit from the full CI machinery, and get
confidence. At an appropriate time we then can just `make dist`, or
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.
Yes, I'm sure anyone who wants to actively develop and support
cockpit on some stable code base would create a similar setup around
a github fork.
If however I'm just a random downstream distro hacker and want to
adjust something for my own flavor, I probably wouldn't want to
setup all this machinery for each and every package I want to change
e.g some documentation link or color scheme.
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 :-)
> In openSUSE a package build is fully unattended, automatic and
> 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
> developers that touched Nodejs before, they just recommended to
> node_modules/. That's not acceptable either IMO as it also would be
> 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
we publish the
cockpit-cache-VERSION.tar.xz tarballs, so you *could* just include
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.
> So I wrote a PoC tool that parses package-lock.json instead.
> 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
present, it will reproduce the exact versions. That's why we
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.
is still not fully offline, as it will always check the npmjs.com
despite package-lock.json. Maybe that can be avoided somehow -- but
case, just grabbing cockpit-cache*.tar.xz seems much easier?
Sure it would be great if npm itself would offer features to print the
url of all locations it wants to fetch as well as options to get those
files fully offline from a local directory.
I'm not a JS developer (yet ;-)) though so it was easier to quickly
hack those python and shell bits than "npm install".
>> 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
license problems in the case npmjs.com
is going down? I can see the
keeping all the original sources at the same downstream location.
cockpit-cache* seems easier to me, but this is certainly a valid
I didn't even think of license problems yet but the ability to track
each tarball separately certainly helps the license reviewers, esp
when those components are used in several packages.
> Also, cockpit-podman wants to use bits of cockpit
> (pkg/lib/patternfly) and the Makefile gets that from git if not
Right, but that's just for upstream git. The `make dist-gzip` rule
includes these files, so the are part of the released tarballs (I
> 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
> that in the Makefiles of modules?
Honestly, I find our current approach of checking out a validated tag
simpler to maintain. For upstream developing against git you
internet, and for building packages out of release tarballs it will
complicate the packaging a lot. We really don't give *any* API
these, and these files are not at all a product.
That's fine. Part of the exercise is building from a git tag resp
master rather than the release tarball. I could also solve that by
making OBS pull from several git repos.
(o_ Ludwig Nussel
SUSE Software Solutions Germany GmbH, GF: Felix Imendörffer
HRB 36809 (AG Nürnberg)