Re: [Rpm-maint] [rpm-software-management/rpm] Question: multi-threaded zstd compression (#1300)
The answer is that threads are not supported right now. Adding the author of the port (@n3npq), he may be interested in? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1300#issuecomment-654641377___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Add %postbuild section / Allow dynamic sub packages (#1239)
So here is some quick and hasty feedback (I was going to write a lot more, but
the laptop battery disagreed).
You need to make it possible to generate what exists in the preamble today,
because otherwise the common case where a SRPM generates a single subpackage,
and you want the SRPM metadata to mirror the single subpackage metadata does
not work. Like you wrote that involves some preamble triaging, to separate what
belongs to the build as a whole, what belongs to the SRPM header, and what
belongs to subpackage headers (I have a fairly good idea of the boundaries,
because my own automation needs forced me to look at the subject in the past
years I don’t claim full knowledge).
%postbuild is misleading and dangerous. You need a dynamic starting point for
every section that succeeds %post, otherwise packagers will just make spec goo
by moving install parts in build so they are executed before the dynamic part,
or conversely moving build parts to install to achieve the reverse. The current
sections help structure packaging and force everyone to use a common packaging
language.
You absolutely need lua evaluation to work in your new section, you absolutely
need this section to see the state of global variables that were set in
previous non dynamic sections, and you absolutely need the state of global
variables set in this section available to the next sections. The shell is a
terrible generation environment. It does not let you collect common processing
code in shared libraries, and it is lacking the explicit rpm.expand lua call
that makes assembling spec fragments at the lua level safe.
You do not need spec file sausage to make several generators coexist, and you
do not need spec file sausage to make generated code coexist with custom
additions. The whole
https://copr.fedorainfracloud.org/coprs/nim/refactoring-forge-patches-auto-call-changelog-fonts/
series show how that can be achieved, almost all the specs in there mix several
generators, and almost all of them add custom processing, and the result is
fine and easy to read within a single unified spec file.
Some will that the whole aim of your change is to get rid of this kind of
multiplexing code (with derogatory comments about this code), but the code
works in all parts of the spec files. Adding a new multiplexing system for a
new section will just layer the new system over the previous ones, since it can
not replace them in the rest of the spec.
Above all do not emulate tags and especially not SourceX which is an abortion
as shown by all the manners people tried to fix it over the years (SourceX;
%{SOURCEX} %{S:} %sources %source_num etc). If you want to emulate something
emulate %sourcelist That was added by people that understand the good way of
automating sources is to get rid of the Source Tag in the first place.
I see no future in full dynamism. There will always be some bit of info that
can not be detected and requires explicit packager declaration. I see a future
in blended approaches, where dynamically detected parts, complete explicit
packager declarations.
Therefore, I do not believe in a future where the spec file does not start with
some explicit declarations. And, while the feature is very cool, there is not
much difference between "you will find Go module X in sources, and its
description is Y, and its spot-approved licensing is Z" and "shall you find Go
module X in sources wink wink its description is Y, and its spot-approved
licensing is Z".
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1239#issuecomment-654481656___
Rpm-maint mailing list
Rpm-maint@lists.rpm.org
http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sync python dependency conversion with pyreq2rpm. (#1299)
Merged #1299 into master. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1299#event-3516927285___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sync python dependency conversion with pyreq2rpm. (#1299)
See my review in https://github.com/gordonmessmer/pyreq2rpm/pull/7 The changes here make sense, yes. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1299#issuecomment-654288456___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Sync python dependency conversion with pyreq2rpm. (#1299)
@hroncok approved this pull request. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1299#pullrequestreview-443152346___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RFE: save the parsed spec in src.rpm (#1241)
Generally speaking it would be great to store more build-time information in the spec. I’ve been requested to store the buildroot state for debuging and reproducibility needs, for example. https://src.fedoraproject.org/fork/nim/rpms/redhat-rpm-config/c/bc4e6a79355f3a2b73abeea7e5c0e1f53b09579e?branch=forge-with-patches-auto-call-auto-changelog-auto-srpm-bump shows how to store more build-time info in the SRPMs using current unchanged rpm. So it does not even need rpm engine changes. However one could argue that writing 13 bytes of spaces in sources files in %sourcelist, just so they exist when %build needs to write to them, is not the most elegant solution. Also calling rpm or rpmspec from within an rpmbuild session is probably not the best of things. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1241#issuecomment-654280267___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] 4.15.1: multiple "-a" parameters in %autosetup are not handled correctly (#1204)
If you wanted to fix %autosetup for multiple archives you’d need to change it to behave the same way as %forgesetup/%forge_prep: 1. move things you’re used to pass on the macro CLI to control variables attached to a specific source file, using naming tricks to implement the attachment 2. make the bettersetup atom process a single archive 3. loop over archives that need processing, calling one bettersetup atom a time, un-stacking the control variables that correspond to the archive being processed A single multiplexing call is quite hard to achieve in generic software and completely above the capabilities of the current rpm argument parser. (the %auto_ framework I posted contains all the basic building blocks to create such looping macros, but you still need to assemble the building blocks in your own bettersetup implementation) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1204#issuecomment-654274451___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] RPM fsverity support (#1203)
fsverity-utils-1.1 which includes fsverity-utils-devel is now available in rawhide and Fedora 32, so it should be possible to build this now. Let me know if you hit any issues. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/1203#issuecomment-654248452___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Question: multi-threaded zstd compression (#1300)
Related to #256. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1300#issuecomment-654130790___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Question: multi-threaded zstd compression (#1300)
I'm curious if `zstd` compression can utilize more threads for a single `.rpm` file? Is there any control of the threading level? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/1300___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
