OK, I've renamed the new function to `rpmGlobPath()` and also squashed the
related commits as they are basically bigger logical units.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2159#issuecomment-1251209180
You are receiving this
@dmnks pushed 3 commits.
6cfa66a541f8e5fc43a70f212fba67f24d177ef9 Add tests for missing files & globs
e9d3b6f6778c058d8dded454dfde7602ca2265d7 Try globs literally when there are no
matches
2ea5d29fa3bab772bee757ac8250f02cb0b1ac37 Refactor processBinaryFile()
--
View it on GitHub:
When sources of a package as well as the spec file are in git
([example](https://github.com/openSUSE/aaa_base/)), the `--build-in-place`
option for `rpmbuild` is quite convenient to build the package directly from
the checkout directory. How does one know whether a spec file is meant for
@sshedi: I suggest taking all of my merged PRs to the OpenPGP code.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2186#discussioncomment-3680832
You are receiving this because you are subscribed to this thread.
Message ID:
Okay, full coverage of all the -f scriptlets added.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#issuecomment-1250993180
You are receiving this because you are subscribed to this thread.
Message ID:
@pmatilai pushed 2 commits.
a4744492d6cc517aabdba2dd208b5ca954a292e5 Update scriptlet -f test to cover all
our scriptlet types
681ab9eecce8533a83ad15c18697e50ee42d87a2 Add support for %preuntrans and
%postuntrans scriptlets
--
View it on GitHub:
Why are we even talking about rejecting such keys/signatures in RPM here? Isn't
this supposed to be handled by the backend in use? IIUC, verification simply
fails in the OpenSSL code if SHA-1 is used in FIPS mode so all we need is make
it clear *why* that is to the user, don't we?
Or is the
One option for Linux would be to apply the changes to an overlayfs, then mount
the overlayfs over the root filesystem.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2193#discussioncomment-3680207
You are receiving this because
Yeah, that was something I was not really happy with. Saving those precious
bits is surly the better way to do it. It also reduces the places that need
touching.
--
Reply to this email directly or view it on GitHub:
Hmm, we actually do have a kind of test for the -f scripts, but it doesn't
cover everything and what it covers it doesn't cover too well. I'll update that
for better coverage.
--
Reply to this email directly or view it on GitHub:
Also fixed now. At this rate, makes one wonder if we shouldn't actually test
these -f things too :laughing:
BTW one intentional difference to your version is that I didn't add separate
RPMSENSE_* flags for these: from dependency (and ordering) POV it doesn't
matter whether they're removals or
@pmatilai pushed 1 commit.
241303be1f2e621a2be33affec412569bdfcdaf5 Add support for %preuntrans and
%postuntrans scriptlets
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177/files/7293a600d1a321bf89835d60ea6b9cb0d592c775..241303be1f2e621a2be33affec412569bdfcdaf5
That'd be simply another bug in this PR, thanks for spotting!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177#issuecomment-1250908570
You are receiving this because you are subscribed to this thread.
Message ID:
Comparing this to
https://github.com/ffesti/rpm/commit/4930200d5de32a7c7f68be2f6c09e3451c80bf95#diff-0abd926819b4533c0286c8e9c82a3f8e4893bb9b8f81024e921d1b0309a909c2
I wonder why you don't need the changes to `processScriptFiles` in
@pmatilai pushed 1 commit.
7293a600d1a321bf89835d60ea6b9cb0d592c775 Add support for %preuntrans and
%postuntrans scriptlets
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2177/files/87405ae63d31f8892025903b7d2c62d7e1ea64da..7293a600d1a321bf89835d60ea6b9cb0d592c775
@pmatilai commented on this pull request.
> @@ -451,6 +465,12 @@ int parseScript(rpmSpec spec, int parsePart)
case PART_POSTTRANS:
pkg->postTransFile = xstrdup(file);
break;
+ case PART_PREUNTRANS:
+ pkg->preTransFile =
@dmnks commented on this pull request.
> @@ -451,6 +465,12 @@ int parseScript(rpmSpec spec, int parsePart)
case PART_POSTTRANS:
pkg->postTransFile = xstrdup(file);
break;
+ case PART_PREUNTRANS:
+ pkg->preTransFile =
The current dependency design comes from nineties and the multilib support
(those dreaded `(64bit)()` postfix markers on dependencies) from the early
millenium was always an ugly hack, necessiated by backwards compatibility. It's
not so much a technically complicated change as it's a
Yes I know. And it would be a braking change to change anything related to
scriptlets. But as I saw RPM is creating a plan for RPM6 and DNF team is
working on DNF5 therefore we have a room for the changes. I think that we need
to do something for inexperienced users with a broken system.
19 matches
Mail list logo
