Re: [Rpm-maint] [rpm-software-management/rpm] RFE: support isolation between %prep/%build/%install/%check (Issue #3050)
> %install should run with a read-only build directory
I don't think this is going to work. E.g. autotoolz-based systems (something in
the autotools, automake, libconf stack) do final preparation steps in the
install target. I think this is inelegant, but not really "wrong". Old meson
versions had a buglet in the i18n module where the po file would be generated
not during build but during installation. But more widely, tools write
installation logs into the build directory. Meson does, I think various Python
tools do (pip?), etc. Anything that gives an "uninstall" command needs to put
the information somewhere.
> %check should run with read-only buildroot to prevent tests from affecting
> packaged content.
People were asking about this a lot in #3010. My motivation for this: build
hygiene and reproducibility. The `%check` section is optional and can be
skipped with `--nocheck` or `--without tests`. The result of a build that
skipped checks should be identical, which would break if anything in `%check`
touches `%{buildroot}`. If `%{buildroot}` is made readonly, we know that we can
skip checks safely and save time. For example, when doing build reproducibility
checks, I'd skip tests, because we're not interested in their result at all,
but we can do that safely only if we are sure that they don't influence package
contents.
> It probably does need writable build-dir because those tests do need to write
> someplace
And same with install: I have seen various sources generate stuff needed for
tests in check targets, not build. In summary, I think that in practice all
phases must be given write access to the build directory.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3050#issuecomment-2065876550
You are receiving this because you are subscribed to this thread.
Message ID: ___
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: ensure unwritable buildroot during %check (Issue #3010)
Closing in favor of a more generic #3050 -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2065857806 You are receiving this because you are subscribed to this thread. Message ID: ___ 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: ensure unwritable buildroot during %check (Issue #3010)
Closed #3010 as completed. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#event-12533384975 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] RFE: support isolation between %prep/%build/%install/%check (Issue #3050)
Ideally, the build scriptlets would be isolated from each other: - %prep unpacks the source, and %build takes place in a separate directory against a read-only source. Obviously not all software can be built outside the source tree, but this would be a nice addon to vpath builds (#2985) - %install wipes buildroot on start, so %build cannot accidentally install stuff. But ideally %install should run with a read-only build directory - install should install, not build. This would've caught #3024. - %check should run with read-only buildroot to prevent tests from affecting packaged content. It probably does need writable build-dir because those tests do need to write someplace. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3050 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] [RFC] rpmbuild, check: verify file hashes (PR #3039)
Rpm already hashes any packaged content cryptographically (SHA256 by default), any such mechanism should utilize that to minimize the extra cost. But this seems like a big extra cost with limited benefit, we're more interested in *preventing* writes across the different stages. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3039#issuecomment-2065842355 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Move OpenSSL code to newer API (PR #2723)
Seems I've managed to throroughly confuse myself with the recent split :joy: So yup, we still need to support the internal parser in 4.19.x but *this* change is not there, and while we still have openssl-related code in >= 4.20, DSA is not part of it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2065833452 You are receiving this because you are subscribed to this thread. Message ID: ___ 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: ensure unwritable buildroot during %check (Issue #3010)
This is not about "preventing XZ", it's just somewhat inspired by it. I really don't know why multiple people are arguing against rpm looking to do some extra packaging hygiene enforcement here. In a similar vein, rpm would prefer an unwritable build directory during %install. Hashing the content is not something this ticket is about. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2065824195 You are receiving this because you are subscribed to this thread. Message ID: ___ 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: ensure unwritable buildroot during %check (Issue #3010)
Yes, this approach will never be complete. Something like the proposed feature is only a building block. For the other stages, there could also be the requirement to not modify files that have been available already. IMHO, other attack vectors should be addressed with other tools. What data would you need to be more willing to accept a PR the implements the requested idea? While the hashing approach might be more IO heavy, it seems like a portable solution. Furthermore, this approach does not require extra permissions for additional jailing. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2065796737 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] %transfiletriggerpostun is not executed (Issue #3048)
Hmm, maybe this only happens if `--reinstall` is used? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3048#issuecomment-2064164044 You are receiving this because you are subscribed to this thread. Message ID: ___ 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: ensure unwritable buildroot during %check (Issue #3010)
There are simpler ways to ensure that `%check` stage does not affect files in the build directory. E.g. we could use an overlayed filesystem (overlayfs, aufs etc.) to mount an empty directory on top of the build directory before executing `%check` but use the original build directory for `%install`. This will have much lower overhead than hashing, but this is unportable between different OSes and will add new dependencies. And I still think this does not solve the real issue because altering binaries will remain possible at `%build` and `%install` stages. A completely different approach is required to avoid this. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2064001168 You are receiving this because you are subscribed to this thread. Message ID: ___ 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: ensure unwritable buildroot during %check (Issue #3010)
I understand the difference between %build and %check, as well as the problem of this could be worked around by future actors. I would still like to understand the potential as a building blocks for hardening. Do you see a path for a hashing-like validation in the %check phase that could be enabled by an additional run time parameter of the tool? This way, feature is available to potential users, but not enabled by default? -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3010#issuecomment-2063917625 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Move OpenSSL code to newer API (PR #2723)
AFAICT the code in question was never released, so there's nothing to fix on your side. (I already fixed it in the "legacy" parser repo) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2063893785 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Move OpenSSL code to newer API (PR #2723)
I would think people can just install those w/o checking the signatures ... but I am not advocating against fixes -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2063889533 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %_target_cpu and various other macros are wrong in during build in BuildArch packages (Issue #3049)
One report of the issue is here: https://bugzilla.redhat.com/show_bug.cgi?id=2069163 but also ran into this in various other circumstances, eg #2319 and %ifarch not working in dynamic spec parts. The spec parsing recurses through build architectures, pushing and popping %_target_cpu as it goes, and the last pop leaves the value to whatever the host is, ie almost certainly wrong and always wrong for noarch packages. It's not just %_target_cpu though, RPM_ARCH environment variable in the build scriptlets gets set from %_arch which is similarly off, and then there's %_libdir, %optflags and all. This affects both dynamically generated .specpart and the templated parts that get expanded during doScript(). -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/issues/3049 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] %transfiletriggerpostun is not executed (Issue #3048)
I have a package with the a few file triggers:
```console
$ rpm -q --filetriggers filesystem|grep -w using -A1
filetriggerin scriptlet (using ) -- /usr/bin
print('FILETRIGGERIN start')
--
filetriggerpostun scriptlet (using ) -- /usr/bin
print('FILETRIGGERPOSTUN /usr/bin start')
--
filetriggerpostun scriptlet (using ) -- /sbin, /usr/sbin
print('FILETRIGGERPOSTUN /usr/sbin start')
--
transfiletriggerpostun scriptlet (using ) -- /sbin, /usr/sbin
print('TRANSFILETRIGGERPOSTUN start')
```
The two last triggers are for the same paths, so if one fires, the other must
too, right?
```console
$ ls -l $(find /usr/sbin/ -type f)
-rwxr-xr-x. 1 root root 45080 Jan 24 01:00 /usr/sbin/kpartx
-rwxr-xr-x. 1 root root 2792336 Feb 27 01:00 /usr/sbin/pdata_tools
$ sudo rpm --reinstall -v
device-mapper-persistent-data-1.0.12-1.fc41.x86_64.rpm
kpartx-0.9.7-7.fc41.x86_64.rpm
Verifying packages...
Preparing packages...
kpartx-0.9.7-7.fc41.x86_64
FILETRIGGERIN start
filetriggerin /usr/bin/kpartx
/usr/bin/kpartx table: 0x5645ad5fa110 /usr/sbin/kpartxtable:
0x5645ad5fa180
FILETRIGGERIN end
device-mapper-persistent-data-1.0.12-1.fc41.x86_64
FILETRIGGERIN start
filetriggerin /usr/bin/cache_check
/usr/bin/cache_checktable: 0x5645ad5e8410 /usr/sbin/cache_check table:
0x5645ad5e8500
filetriggerin /usr/bin/cache_dump
/usr/bin/cache_dump table: 0x5645ad5ae380 /usr/sbin/cache_dumptable:
0x5645ad885bf0
filetriggerin /usr/bin/cache_metadata_size
/usr/bin/cache_metadata_sizetable: 0x5645b1132300
/usr/sbin/cache_metadata_size table: 0x5645ad5f7710
filetriggerin /usr/bin/cache_repair
/usr/bin/cache_repair table: 0x5645ad5f9e70 /usr/sbin/cache_repair table:
0x5645ad5f9eb0
filetriggerin /usr/bin/cache_restore
/usr/bin/cache_restore table: 0x5645b11321b0 /usr/sbin/cache_restore table:
0x5645b11321f0
filetriggerin /usr/bin/cache_writeback
/usr/bin/cache_writebacktable: 0x5645ad668690
/usr/sbin/cache_writeback table: 0x5645ad6686d0
filetriggerin /usr/bin/era_check
/usr/bin/era_check table: 0x5645ad653d30 /usr/sbin/era_check table:
0x5645ad653d70
filetriggerin /usr/bin/era_dump
/usr/bin/era_dump table: 0x5645ad6541d0 /usr/sbin/era_dump table:
0x5645ad654210
filetriggerin /usr/bin/era_invalidate
/usr/bin/era_invalidate table: 0x5645ad5f5670 /usr/sbin/era_invalidate
table: 0x5645ad5f56b0
filetriggerin /usr/bin/era_restore
/usr/bin/era_restoretable: 0x5645ad5f5b10 /usr/sbin/era_restore table:
0x5645ad5f5b50
filetriggerin /usr/bin/pdata_tools
/usr/bin/pdata_toolstable: 0x5645b10ab510 /usr/sbin/pdata_tools table:
0x5645b10ab550
filetriggerin /usr/bin/thin_check
/usr/bin/thin_check table: 0x5645b10ab9b0 /usr/sbin/thin_checktable:
0x5645b10ab9f0
filetriggerin /usr/bin/thin_delta
/usr/bin/thin_delta table: 0x5645b10abe50 /usr/sbin/thin_deltatable:
0x5645b10abe90
filetriggerin /usr/bin/thin_dump
/usr/bin/thin_dump table: 0x5645ad658530 /usr/sbin/thin_dump table:
0x5645ad658570
filetriggerin /usr/bin/thin_ls
/usr/bin/thin_lstable: 0x5645ad6589d0 /usr/sbin/thin_ls table:
0x5645ad658a10
filetriggerin /usr/bin/thin_metadata_pack
/usr/bin/thin_metadata_pack table: 0x5645ad658e70
/usr/sbin/thin_metadata_packtable: 0x5645ad658eb0
filetriggerin /usr/bin/thin_metadata_size
/usr/bin/thin_metadata_size table: 0x5645ad8b67c0
/usr/sbin/thin_metadata_sizetable: 0x5645ad8b6800
filetriggerin /usr/bin/thin_metadata_unpack
/usr/bin/thin_metadata_unpack table: 0x5645ad8b6c60
/usr/sbin/thin_metadata_unpack table: 0x5645ad8b6ca0
filetriggerin /usr/bin/thin_repair
/usr/bin/thin_repairtable: 0x5645ad8b7100 /usr/sbin/thin_repair table:
0x5645ad8b7140
filetriggerin /usr/bin/thin_restore
/usr/bin/thin_restore table: 0x5645ad8b75a0 /usr/sbin/thin_restore table:
0x5645ad8b75e0
filetriggerin /usr/bin/thin_rmap
/usr/bin/thin_rmap table: 0x5645ad8b7a40 /usr/sbin/thin_rmap table:
0x5645ad8b7a80
filetriggerin /usr/bin/thin_trim
/usr/bin/thin_trim table: 0x5645ad8b7ee0 /usr/sbin/thin_trim table:
0x5645ad8b7f20
FILETRIGGERIN end
kpartx-0.9.7-7.fc41.x86_64
FILETRIGGERPOSTUN /usr/sbin start
filetriggerpostun /usr/sbin/kpartx
/usr/bin/kpartx table: 0x5645ad654430 /usr/sbin/kpartxnil
Symlinking /usr/sbin/kpartx->/usr/bin/kpartx
FILETRIGGERPOSTUN /usr/sbin stop
device-mapper-persistent-data-1.0.12-1.fc41.x86_64
FILETRIGGERPOSTUN /usr/sbin start
filetriggerpostun /usr/sbin/cache_check
/usr/bin/cache_checktable: 0x5645ad83c6b0 /usr/sbin/cache_check nil
Symlinking /usr/sbin/cache_check->/usr/bin/cache_check
filetriggerpostun /usr/sbin/cache_dump
/usr/bin/cache_dump table: 0x5645ad556110 /usr/sbin/cache_dumpnil
Symlinking /usr/sbin/cache_dump->/usr/bin/cache_dump
filetriggerpostun /usr/sbin/cache_metadata_size
/usr/bin/cache_metadata_sizetable: 0x5645ad5ae380
Re: [Rpm-maint] [rpm-software-management/rpm] Relax openssl version requirement (PR #3045)
Merged #3045 into master. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3045#event-12520804092 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Relax openssl version requirement (PR #3045)
Oh, of course. I'm already forgetting I just split a good chunk of that code out :laughing: -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3045#issuecomment-2063473913 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Move OpenSSL code to newer API (PR #2723)
There may not be DSA keys in active use but they do exist in old distros and packages people may want to install for whatever reason. If we broke it we should fix it. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2723#issuecomment-2063471380 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Relax openssl version requirement (PR #3045)
Not exactly. It is because you removed all the non-digest code from digest_openssl.c. (Florian updated the signature verification code to no longer use deprecated functions, that's why he had to bump the required version.) -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3045#issuecomment-2063470614 You are receiving this because you are subscribed to this thread. Message ID: ___ 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 error messages for url helper calls (PR #3041)
There should be a test for the case where the urlhelper is missing - it's what we can easily test, and also happens to be the case we're also most interested in for the bug. > $ ./tools/rpm --define "_urlhelper /not/there" -qp > https://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/39/Everything/x86_64/Packages/3/389-ds-base-snmp-2.4.5-1.fc39.x86_64.rpm error: Could not find url helper: "/not/there" error: open of https://ftp.funet.fi/pub/mirrors/fedora.redhat.com/pub/fedora/linux/updates/39/Everything/x86_64/Packages/3/389-ds-base-snmp-2.4.5-1.fc39.x86_64.rpm failed: No such file or directory Like I said (elsewhere), I've poked at this thing before. And I remember now, the reason I abandoned it was because I didn't like the "improved" behavior that great either - the latter message is pretty misleading even if the reason is in the line above. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3041#issuecomment-2063440048 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Relax openssl version requirement (PR #3045)
So the API we updated to just now was there all this time? Oh well... -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3045#issuecomment-2063422093 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
...aaand then in the exact reverse order to make up a nice refactoring series. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047#issuecomment-2063363180 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
@pmatilai pushed 3 commits. 9e9a3fa747a285876726c33ca8d4df15a6f6759b Refactor getSection() to more generally useful 106c81b7050c255e4281eb3f4717c601e40fb7e9 Refactor build script parse calls to a helper 39ff076a33d645ec4e40b0ca07c7ecad74df0912 Fix build scriptlet append/prepend interaction with Buildsystem -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047/files/b50ac2d506491e3651797b4a4e2f133731c2ddb0..39ff076a33d645ec4e40b0ca07c7ecad74df0912 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
@pmatilai pushed 1 commit. b50ac2d506491e3651797b4a4e2f133731c2ddb0 Refactor getSection() to more generally useful -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047/files/3bf011d4aa230f120f07d205d5e9bff710b5e8c6..b50ac2d506491e3651797b4a4e2f133731c2ddb0 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
Re: [Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
@pmatilai pushed 1 commit. 3bf011d4aa230f120f07d205d5e9bff710b5e8c6 Refactor parseBuildScript() to take spec PART_* numbers instead of names -- View it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047/files/4a8d86ea57040ff73d5b32a65a28a9e8cec6ff14..3bf011d4aa230f120f07d205d5e9bff710b5e8c6 You are receiving this because you are subscribed to this thread. Message ID: ___ 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 prepend and append modes for all our normal build scriptlets (PR #2728)
@pmatilai commented on this pull request. > @@ -461,6 +461,13 @@ when name is omitted, the description refers to the main > package. Package build is divided into multiple separate steps, each executed in a separate shell. +Only one of each section can be present in a spec, but all build scriptlets +except for `%prep` accept options `-a` and `-p`, for append and prepend mode. +Append and prepend append or prepend lines to the section in the order they +appear in the spec. Both append and prepend can be used multiple times and +without other restrictions, but a section without either mode can only +appear first (eg `%build` cannot follow `%build -p`). Turns out what felt artificial, was in fact an artificial limit of the implementation. https://github.com/rpm-software-management/rpm/pull/3047 does away with that limitation, -a/-p are always applied relative to the main section if it exists, otherwise the first fragment is used as the base. Makes a lot more sense that way. -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/2728#discussion_r1570157804 You are receiving this because you are subscribed to this thread. Message ID: ___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
[Rpm-maint] [rpm-software-management/rpm] Fix build scriptlet append/prepend interaction with Buildsystem (PR #3047)
The append and prepend modes got added before the declarative Buildsystem, and did not get thoroughly tested with it. The existing %build -a test didn't actually work but automake handling the build in %install masked the issue embarrasingly. As the Buildsystem is parsed after everything else, there's no way the previous append/prepend implementation could work correctly with it. Do what we should've done from the start: collect any prepend/append stuff into separate data structures and apply them after everything else has been parsed. This also lifts the artificial sounding restriction wrt the corresponding main section:it's really the right thing to do, even if it's a bit more code. Make the tests wrt buildsystem much more thorough to ensure it all really works, blush. Fixes: #3024 You can view, comment on, or merge this pull request online at: https://github.com/rpm-software-management/rpm/pull/3047 -- Commit Summary -- * Fix build scriptlet append/prepend interaction with Buildsystem -- File Changes -- M build/parseSimpleScript.c (23) M build/parseSpec.c (72) M build/rpmbuild_internal.h (11) M build/spec.c (2) M docs/manual/spec.md (7) M tests/data/SPECS/amhello.spec (22) M tests/rpmbuild.at (14) -- Patch Links -- https://github.com/rpm-software-management/rpm/pull/3047.patch https://github.com/rpm-software-management/rpm/pull/3047.diff -- Reply to this email directly or view it on GitHub: https://github.com/rpm-software-management/rpm/pull/3047 You are receiving this because you are subscribed to this thread. Message ID:___ Rpm-maint mailing list Rpm-maint@lists.rpm.org http://lists.rpm.org/mailman/listinfo/rpm-maint
