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)