https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
== Owner ==
* Name: [[User:pmatilai|Panu Matilainen]] * Email: pmatilai@redhat.com
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include * A more intuitive conditional builds macro `%bcond` * A more robust and secure `--restore` functionality * Long-standing `%patch` quirks fixed * Weak dependencies accept qualifiers like `meta` and `pre` now * New interactive shell for working with macros (`rpmspec --shell`) and embedded Lua (`rpmlua`) * New `%conf` spec section for build configuration * New `rpmuncompress` cli tool simplifies unpacking multiple sources * Numerous macro improvements and fixes * Numerous OpenPGP parser correctness and security fixes
== Benefit to Fedora == The main benefits of this release are increased security and packaging experience improvements, see above for details.
== Scope == * Proposal owners: ** Rebase RPM ** Assist with dealing with incompatibilities
* Other developers: ** Test new release, report issues and bugs
* Release engineering: [https://pagure.io/releng/issue/10742 #10742]
* Policies and guidelines: N/A (not needed for this Change). Utilizing new rpm features is subject to packaging guidelines but othe
* Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A (no relation to current objectives)
== Upgrade/compatibility impact == There are no noteworthy compatibility issues with this release.
== How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation.
== User Experience == There are no major differences in the normal user experience.
== Dependencies == * No new dependencies are introduced in this release * Other changes are known to be affected * Library soname will not change so no rebuilds are required
== Contingency Plan == * Contingency mechanism: Revert back to RPM 4.17 * Contingency deadline: Beta freeze * Blocks release? No
== Documentation == Work-in-progress release notes at https://rpm.org/wiki/Releases/4.18.0 and reference manual at https://github.com/rpm-software-management/rpm/blob/master/doc/manual/index....
== Release Notes == https://rpm.org/wiki/Releases/4.18.0
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
== Owner ==
- Name: [[User:pmatilai|Panu Matilainen]]
- Email: pmatilai@redhat.com
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include
- A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an extremely welcome change and I would like to shower praise upon everyone who worked on it.
One thing I noticed while perusing the new docs: the documentation for %autosetup is incomplete. The doc reads: "Generally %autosetup accepts the same arguments as %setup does", but the section on %setup no longer exists. Only the unique arguments for %autosetup are listed.
[1] https://rpm-software-management.github.io/rpm/manual/conditionalbuilds.html
On 4/7/22 19:47, Stephen Gallagher wrote:
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton bcotton@redhat.com wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
== Owner ==
- Name: [[User:pmatilai|Panu Matilainen]]
- Email: pmatilai@redhat.com
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include
- A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an extremely welcome change and I would like to shower praise upon everyone who worked on it.
One thing I noticed while perusing the new docs: the documentation for %autosetup is incomplete. The doc reads: "Generally %autosetup accepts the same arguments as %setup does", but the section on %setup no longer exists. Only the unique arguments for %autosetup are listed.
I don't think our docs ever covered %setup, that would've been max-rpm more likely. Of course, %setup *should* be covered by our docs, and ditto for %patch.
- Panu -
On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton bcotton@redhat.com wrote:
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include
- A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an extremely welcome change and I would like to shower praise upon everyone who worked on it.
Big +1 from me too, this is so good to see. Thanks Panu & all.
Regards, Joe
On 27. 04. 22 10:36, Joe Orton wrote:
On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton bcotton@redhat.com wrote:
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include
- A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an extremely welcome change and I would like to shower praise upon everyone who worked on it.
Big +1 from me too, this is so good to see. Thanks Panu & all.
I like this so much I've opened Fedora 36 and 35 backports:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/182 https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/183
Will also try to see if this is technically possible in c9s.
On Wed, Apr 27, 2022 at 5:08 AM Miro Hrončok mhroncok@redhat.com wrote:
On 27. 04. 22 10:36, Joe Orton wrote:
On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton bcotton@redhat.com wrote:
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include
- A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an extremely welcome change and I would like to shower praise upon everyone who worked on it.
Big +1 from me too, this is so good to see. Thanks Panu & all.
I like this so much I've opened Fedora 36 and 35 backports:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/182 https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/183
Will also try to see if this is technically possible in c9s.
It should be possible to put it in epel-rpm-macros at the worst, no? (Related: can we get a backport to EPEL 8 and EPEL 9?)
On 27. 04. 22 17:53, Stephen Gallagher wrote:
On Wed, Apr 27, 2022 at 5:08 AM Miro Hrončok mhroncok@redhat.com wrote:
On 27. 04. 22 10:36, Joe Orton wrote:
On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton bcotton@redhat.com wrote:
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include
- A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an extremely welcome change and I would like to shower praise upon everyone who worked on it.
Big +1 from me too, this is so good to see. Thanks Panu & all.
I like this so much I've opened Fedora 36 and 35 backports:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/182 https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/183
Will also try to see if this is technically possible in c9s.
It should be possible to put it in epel-rpm-macros at the worst, no? (Related: can we get a backport to EPEL 8 and EPEL 9?)
What I've meant by "technically possible": Does the RPM version in EL 9 support the syntax used in the macro?
If it does, it can go to EPEL 9 and even to c9s eventually, if accepted. If it doesn't, we might need to use a different syntax which would require more work. This also applies to EL 8, but I suspect even more problems there.
On 4/27/22 19:09, Miro Hrončok wrote:
On 27. 04. 22 17:53, Stephen Gallagher wrote:
On Wed, Apr 27, 2022 at 5:08 AM Miro Hrončok mhroncok@redhat.com wrote:
On 27. 04. 22 10:36, Joe Orton wrote:
On Thu, Apr 07, 2022 at 12:47:25PM -0400, Stephen Gallagher wrote:
On Thu, Apr 7, 2022 at 12:24 PM Ben Cotton bcotton@redhat.com wrote:
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include
- A more intuitive conditional builds macro `%bcond`
I looked this up[1] because it caught my attention. This is an extremely welcome change and I would like to shower praise upon everyone who worked on it.
Big +1 from me too, this is so good to see. Thanks Panu & all.
I like this so much I've opened Fedora 36 and 35 backports:
https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/182 https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/183
Will also try to see if this is technically possible in c9s.
It should be possible to put it in epel-rpm-macros at the worst, no? (Related: can we get a backport to EPEL 8 and EPEL 9?)
What I've meant by "technically possible": Does the RPM version in EL 9 support the syntax used in the macro?
If it does, it can go to EPEL 9 and even to c9s eventually, if accepted. If it doesn't, we might need to use a different syntax which would require more work. This also applies to EL 8, but I suspect even more problems there.
The %bcond macro relies on a %[] expression which requires rpm >= 4.16, so EL9 should be okay, older ones wont work.
- Panu -
On Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton wrote:
- New interactive shell for working with macros (`rpmspec --shell`)
and embedded Lua (`rpmlua`)
That sounds cool. Can this be used to do standalone interpretation of <lua> scriptlets? I'm wondering about the issue that we have with rpm-ostree, which only supports bash scriptlets, so we end up rewriting <lua> scriptlets and filetriggers to bash for the sake of rpm-ostree.
- New `%conf` spec section for build configuration
Any docs on this?
- New `rpmuncompress` cli tool simplifies unpacking multiple sources
- Numerous macro improvements and fixes
- Numerous OpenPGP parser correctness and security fixes
Zbyszek
On 4/7/22 20:14, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton wrote:
- New interactive shell for working with macros (`rpmspec --shell`)
and embedded Lua (`rpmlua`)
That sounds cool. Can this be used to do standalone interpretation of <lua> scriptlets? I'm wondering about the issue that we have with rpm-ostree, which only supports bash scriptlets, so we end up rewriting <lua> scriptlets and filetriggers to bash for the sake of rpm-ostree.
Well, it's a Lua interpeter, and so you can use it to execute Lua scripts from a file using the rpm embedded Lua interpreter so you'll have the same extensions loaded. It's not the same as getting executed from inside rpm transaction though because all sorts of context is missing, and this is not the intended use-case of the thing. That said, assuming the caller sets up scriptlet arguments and other state as per expectations, I don't see why simple scriptlets would not work. File triggers will not.
- New `%conf` spec section for build configuration
Any docs on this?
There's a brief blurb in https://rpm-software-management.github.io/rpm/manual/spec.html (not much to say really), for rationale see https://github.com/rpm-software-management/rpm/pull/1932
- Panu -
Dne 08. 04. 22 v 10:56 Panu Matilainen napsal(a):
On 4/7/22 20:14, Zbigniew Jędrzejewski-Szmek wrote:
On Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton wrote:
- New interactive shell for working with macros (`rpmspec --shell`)
and embedded Lua (`rpmlua`)
That sounds cool. Can this be used to do standalone interpretation of <lua> scriptlets? I'm wondering about the issue that we have with rpm-ostree, which only supports bash scriptlets, so we end up rewriting <lua> scriptlets and filetriggers to bash for the sake of rpm-ostree.
Well, it's a Lua interpeter, and so you can use it to execute Lua scripts from a file using the rpm embedded Lua interpreter so you'll have the same extensions loaded. It's not the same as getting executed from inside rpm transaction though because all sorts of context is missing, and this is not the intended use-case of the thing. That said, assuming the caller sets up scriptlet arguments and other state as per expectations, I don't see why simple scriptlets would not work. File triggers will not.
I was just thinking about something similar yesterday in the context of rhbz#2073170. The issue is that there is redhat-rpm-config macro using Lua string patterns. So if there was a way to reuse the patterns also from e.g. the build section, that would be useful.
Vít
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
- New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building.
Different build- and language ecosystems come with their own helper macros, but rpm has helpers for autotools based builds such as itself which typically look like this:
%conf %configure
In context of autotools, sources usually bundle a configure script. To follow the open source way (and ensure portability to new platform and include autotools fixes), building from the real sources is desired. Hence I do my best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
%prep %prep %autosetup %autosetup autoreconf -fi
%conf %conf autoreconf -fi %configure %configure
%build %build %make_build %make_build
Please bear in mind that %prep usually contains other non-declarative twists like pruning bundled code, correcting file permissions etc.
-- Petr
On 4/8/22 12:16, Petr Pisar wrote:
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
- New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building.
Different build- and language ecosystems come with their own helper macros, but rpm has helpers for autotools based builds such as itself which typically look like this:
%conf %configure
In context of autotools, sources usually bundle a configure script. To follow the open source way (and ensure portability to new platform and include autotools fixes), building from the real sources is desired. Hence I do my best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
%prep %prep %autosetup %autosetup autoreconf -fi %conf %conf autoreconf -fi %configure %configure %build %build %make_build %make_buildPlease bear in mind that %prep usually contains other non-declarative twists like pruning bundled code, correcting file permissions etc.
My personal opinion is that autoreconf, where used, belongs to %prep because it can quite literally install bits required by the build system.
It's also something you only run once after unpacking the sources, not every time you configure. Which suggests that they should be in different sections. The same logic is applicable to other related steps.
- Panu -
On Fri, Apr 8, 2022 at 6:34 AM Panu Matilainen pmatilai@redhat.com wrote:
On 4/8/22 12:16, Petr Pisar wrote:
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
- New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building. Different build- and language ecosystems come with their own helper macros, but rpm has helpers for autotools based builds such as itself which typically look like this: %conf %configureIn context of autotools, sources usually bundle a configure script. To follow the open source way (and ensure portability to new platform and include autotools fixes), building from the real sources is desired. Hence I do my best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
%prep %prep %autosetup %autosetup autoreconf -fi %conf %conf autoreconf -fi %configure %configure %build %build %make_build %make_buildPlease bear in mind that %prep usually contains other non-declarative twists like pruning bundled code, correcting file permissions etc.
My personal opinion is that autoreconf, where used, belongs to %prep because it can quite literally install bits required by the build system.
It's also something you only run once after unpacking the sources, not every time you configure. Which suggests that they should be in different sections. The same logic is applicable to other related steps.
I would disagree and suggest it go into %conf. My reasoning for this is that autoreconf + configure is combined for most other build systems and we want those to run in %conf, so consistency beckons that we do the same here. It also ensures we don't need anything more than tarball unpacking and patching dependencies for %prep.
On 4/8/22 14:17, Neal Gompa wrote:
On Fri, Apr 8, 2022 at 6:34 AM Panu Matilainen pmatilai@redhat.com wrote:
On 4/8/22 12:16, Petr Pisar wrote:
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
- New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building. Different build- and language ecosystems come with their own helper macros, but rpm has helpers for autotools based builds such as itself which typically look like this: %conf %configureIn context of autotools, sources usually bundle a configure script. To follow the open source way (and ensure portability to new platform and include autotools fixes), building from the real sources is desired. Hence I do my best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
%prep %prep %autosetup %autosetup autoreconf -fi %conf %conf autoreconf -fi %configure %configure %build %build %make_build %make_buildPlease bear in mind that %prep usually contains other non-declarative twists like pruning bundled code, correcting file permissions etc.
My personal opinion is that autoreconf, where used, belongs to %prep because it can quite literally install bits required by the build system.
It's also something you only run once after unpacking the sources, not every time you configure. Which suggests that they should be in different sections. The same logic is applicable to other related steps.
I would disagree and suggest it go into %conf. My reasoning for this is that autoreconf + configure is combined for most other build systems and we want those to run in %conf, so consistency beckons that we do the same here. It also ensures we don't need anything more than tarball unpacking and patching dependencies for %prep.
I used "personal opinion" very much on purpose, as there would be as many opinions on this as there are observers. My opinion is biased towards what makes sense from a staged rpmbuild POV, for a --rebuild end result all of this is academic.
- Panu -
On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
- New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building.
Different build- and language ecosystems come with their own helper macros, but rpm has helpers for autotools based builds such as itself which typically look like this:
%conf %configure
In context of autotools, sources usually bundle a configure script. To follow the open source way (and ensure portability to new platform and include autotools fixes), building from the real sources is desired. Hence I do my best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
For me the important distinction is that %prep should *not* execute the code from the package: it should just unpack, apply patches and fixups, change permissions, etc. This all should be done using external tools, and not scripts from the package itself. This way it is possible do 'fedpkg prep' or equivalent and view the sources without executing any commands from the package. So even if the package does not want to run on a given architecture, or upstream does something stupid or hostile, %prep remains reliable. (This also means that %prep should rather do less than more.)
If autoreconf is done using the external 'autoreconf' command, then %prep seems appropriate. Some packages have ./autogen.sh or similar, and that I'd put in one of the later sections.
Zbyszek
While the autoreconf command is “external,” it does implicitly execute m4 scripts, often including some that are included in the package source distribution, in order to generate the configure script. Note also that autogen.sh is rarely more than a trivial one-to-five-line wrapper around autoreconf.
Sometimes autoreconf also needs m4 scripts that are installed with the -devel packages of various dependencies. For example, gtk2-devel provides /usr/share/aclocal/gtk-2.0.m4, which provides the AM_PATH_GTK_2_0 macro, which can be used in dependent packages’ configure.ac files to generate GTK2 detection code. Such packages would need gtk2-devel installed in order to run autoreconf. Sometimes copies of these m4 files are provided with the dependent package sources, and sometimes they aren’t.
This is why I don’t personally like autoreconf happening in %prep: it can add arbitrary dependencies (not just autoconf/automake/libtool), and I think it is valuable to be able to run “fedpkg prep” or similar without installing extra dependencies on the packager’s system.
On 4/12/22 10:04, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
V Thu, Apr 07, 2022 at 12:13:42PM -0400, Ben Cotton napsal(a):
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
[...]
- New `%conf` spec section for build configuration
RPM documenation reads:
In %conf, the unpacked sources are configured for building.
Different build- and language ecosystems come with their own helper macros, but rpm has helpers for autotools based builds such as itself which typically look like this:
%conf %configure
In context of autotools, sources usually bundle a configure script. To follow the open source way (and ensure portability to new platform and include autotools fixes), building from the real sources is desired. Hence I do my best to call "autoreconf -fi" before %configure.
Where should autoreconf be placed? %pre or %conf?
For me the important distinction is that %prep should *not* execute the code from the package: it should just unpack, apply patches and fixups, change permissions, etc. This all should be done using external tools, and not scripts from the package itself. This way it is possible do 'fedpkg prep' or equivalent and view the sources without executing any commands from the package. So even if the package does not want to run on a given architecture, or upstream does something stupid or hostile, %prep remains reliable. (This also means that %prep should rather do less than more.)
If autoreconf is done using the external 'autoreconf' command, then %prep seems appropriate. Some packages have ./autogen.sh or similar, and that I'd put in one of the later sections.
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
V Tue, Apr 12, 2022 at 04:04:35PM +0200, Zbigniew Jędrzejewski-Szmek napsal(a):
On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
Where should autoreconf be placed? %pre or %conf?
For me the important distinction is that %prep should *not* execute the code from the package: it should just unpack, apply patches and fixups, change permissions, etc. This all should be done using external tools, and not scripts from the package itself. This way it is possible do 'fedpkg prep' or equivalent and view the sources without executing any commands from the package. So even if the package does not want to run on a given architecture, or upstream does something stupid or hostile, %prep remains reliable. (This also means that %prep should rather do less than more.)
If autoreconf is done using the external 'autoreconf' command, then %prep seems appropriate. Some packages have ./autogen.sh or similar, and that I'd put in one of the later sections.
That's a good point. However, autoreconf tool expands m4 macros in configure.ac and whatever aclocal macro directory or file provided with the sources. I'm not an expert in m4, but according to a documentation m4 has recursion and conditions, hence you can have an infinite loop. Thus, in the the manner of your classification, I'd consider autoreconf not to be suitable for %prep.
-- Petr
On 4/12/22 11:22, Petr Pisar wrote:
V Tue, Apr 12, 2022 at 04:04:35PM +0200, Zbigniew Jędrzejewski-Szmek napsal(a):
On Fri, Apr 08, 2022 at 11:16:59AM +0200, Petr Pisar wrote:
Where should autoreconf be placed? %pre or %conf?
For me the important distinction is that %prep should *not* execute the code from the package: it should just unpack, apply patches and fixups, change permissions, etc. This all should be done using external tools, and not scripts from the package itself. This way it is possible do 'fedpkg prep' or equivalent and view the sources without executing any commands from the package. So even if the package does not want to run on a given architecture, or upstream does something stupid or hostile, %prep remains reliable. (This also means that %prep should rather do less than more.)
If autoreconf is done using the external 'autoreconf' command, then %prep seems appropriate. Some packages have ./autogen.sh or similar, and that I'd put in one of the later sections.
That's a good point. However, autoreconf tool expands m4 macros in configure.ac and whatever aclocal macro directory or file provided with the sources. I'm not an expert in m4, but according to a documentation m4 has recursion and conditions, hence you can have an infinite loop. Thus, in the the manner of your classification, I'd consider autoreconf not to be suitable for %prep.
-- Petr
M4 can also execute arbitrary shell commands.
On 4/7/22 19:13, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
FWIW, this is in rawhide now. Submitted yesterday already but some bodhi/koji delay caused it to only go live today AFAICS.
As per the usual drill, if you so much as suspect a bug/regression in rpm, don't dwell on it, just go ahead and file it. A few possible false positives early on is a cheap price to pay compared to having to do rebuilds en masse later.
- Panu -
On Tue, Apr 26, 2022 at 11:50 AM Panu Matilainen pmatilai@redhat.com wrote:
On 4/7/22 19:13, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
FWIW, this is in rawhide now. Submitted yesterday already but some bodhi/koji delay caused it to only go live today AFAICS.
As per the usual drill, if you so much as suspect a bug/regression in rpm, don't dwell on it, just go ahead and file it. A few possible false positives early on is a cheap price to pay compared to having to do rebuilds en masse later.
I would have appreciated it if you at least waited with pushing it to rawhide until the FESCo ticket was approved...
Fabio
On 4/26/22 12:53, Fabio Valentini wrote:
On Tue, Apr 26, 2022 at 11:50 AM Panu Matilainen pmatilai@redhat.com wrote:
On 4/7/22 19:13, Ben Cotton wrote:
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
FWIW, this is in rawhide now. Submitted yesterday already but some bodhi/koji delay caused it to only go live today AFAICS.
As per the usual drill, if you so much as suspect a bug/regression in rpm, don't dwell on it, just go ahead and file it. A few possible false positives early on is a cheap price to pay compared to having to do rebuilds en masse later.
I would have appreciated it if you at least waited with pushing it to rawhide until the FESCo ticket was approved...
Indeed. I do know how the process goes, been through it many, many times, and not sure what made me short-circuit it this time around. Perhaps it was the distressed state of mind from our dog getting hit by a car on Monday morning.
Apologies for that, and having seen the fesco meeting log - indeed it would not hurt to say wait for explicit APPROVED stamp, no matter how obvious it seems.
Oh, and the dog appears okay. Seems we were very, very lucky there.
- Panu -
-
Ben Beasley -
Ben Cotton -
Demi Marie Obenour -
Fabio Valentini -
Joe Orton -
Miro Hrončok -
Neal Gompa -
Panu Matilainen -
Petr Pisar -
Stephen Gallagher -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek