Dne 21. 02. 20 v 15:57 Martin Sehnoutka napsal(a):
This process is unfortunately not fully automated and therefore
requires a certain amount of human effort.
This is an important sentence. Let's save it for later as [1]
The proposal itself is fairly simple: Let’s stop packaging all Go and
Rust libraries into RPM and install them to the
buildroot in the upstream format instead.
...
* We want to know what exactly was used to build the RPM to ensure integrity. This is
possible with upstream tarballs
as well as with RPMs. Just store a hash of the tarball.
* There should be no maintenance cost. If we would avoid modifying the upstream package
it would be the ideal case.
* It should be possible to patch the library in case of severe issues like CVEs. This is
a contradiction to the
previous point, but it could be solved by unpacking the upstream package into a git
repository and creating a new,
modified package in upstream format from it.
* It should be possible to run the build locally in exactly the same way Koji does it.
This is just about exposing our
“registry” of packages to the public Internet.
Whoa. That is a lots of requirements. You can easily get lost in them. And very likely
unable to reach your goal.
Finally, the implementation could be something like this:
A service like release-monitoring could monitor the upstream projects for new releases
(e.g. NPM has a RSS feed). Every
time there is a new release it would automatically synchronize our own Fedora-specific
registry, which would in turn be
accessible in buildroot.
So bits in wild internet suddenly become clean when we duplicate them into our
infrastructure?
And this is a lot of bits. The storage has a price :(
Additionally, even when the build in Koji (or Mock in general) is offline, the
dependencies are installed with internet
enabled. If you teach Mock how to call native crate/rubygem/.. before the actual build
start, you will have most of the
work done.
Many people tried to achieve this (non-RPM content in rpm). It may sound simple, but this
is a **huge** task. And for
example: 1) making this technically possible and 2) allow this in Fedora are completely
different task with different
ETA and different chances for success.
Why are you trying to come with this proposal? Do you think it will be much easier than
automating the packaging? (see
[1] above). I, personally, think automating the packaging is a better way to go. Still
huge, though.
What I would recommend is either:
1) Focus on the automation. Especially automation of license check. There has been several
mentiond on this list in past
few months. We can learn a lot from OpenSuse regarding this.
2) Improve the automation of packaging.
See
https://copr.fedorainfracloud.org/coprs/iucar/cran/ or our previous attempts to
rebuild PYPI and Rubygems where we
imporoved spec generators a lot.
3) If you really want to focus on non-RPM content - you may add something like this to
SPEC files:
BuildRequires: native::crate(foo)
with the semantics that rpm-build:
1) will ignore anything with native:: prefix
2) or check if foo is present on system using crate (and not as rpm)
This has a benefit that you need to modify only rpm-build, but not rpm itself.
When you choose the first option, then you can levarage
https://fedoraproject.org/wiki/Changes/DynamicBuildRequires
and emit this dependency and it can be catched by Mock and installed before the rpm-build
is called.
Focus on making this technically possible. And only then start discussion if we want to
have this enabled in Fedora.
This will give you a grace period where this feature can mature.
--
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys