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 _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
