Merged #2583 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2583#event-9915782137
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
@dmnks approved this pull request.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2573#pullrequestreview-1547356492
You are receiving this because you are subscribed to this thread.
Message ID:
Now that the script has the `bash` shebang, shouldn't we make use of `local`
and declare the function-local variables as such? Currently, they are all
redefined on entry and not used outside of the functions, but if we change
something in the script in the future and forget about it...
--
@dmnks commented on this pull request.
> @@ -470,11 +470,13 @@ static rpmdbMatchIterator initQueryIterator(QVA_t qva,
> rpmts ts, const char * ar
if (mi == NULL) {
struct stat sb;
- if (lstat(fn, ) != 0)
+ char * full_fn = rpmGenPath(rpmtsRootDir(ts),
Other than the above, the PR looks sane, nice work!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2573#issuecomment-1651444355
You are receiving this because you are subscribed to this thread.
Message ID:
Add a bit more text to `tests/README.md` about the new test-suite layout from
#2559 and while at it, write a short howto on test writing, too. A file
describing the mktree interface (`mktree.README`) may also be helpful.
--
Reply to this email directly or view it on GitHub:
Please see the commit messages for details.
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2610
-- Commit Summary --
* Support common mktree.fedora image in build dirs
* Simplify BYPRODUCTS in make tree
* Clean up
@dmnks pushed 3 commits.
1c94ddb065e2e9625e0d8ab0f1efde6a4042459c Support common mktree.fedora image in
build dirs
5c5b6e44cbf48f9cbe21ee6c0b630ecad11cb014 Simplify BYPRODUCTS in "make tree"
0ea0c0fa09573152ea389735e18b96f822dd69a5 Clean up dnf() function in "make env"
--
View it on GitHub:
OK, slept on it, let's go with the original approach, i.e. commit
1c94ddb065e2e9625e0d8ab0f1efde6a4042459c. It's better to just keep things tidy.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2610#issuecomment-1674380853
You are
Hmm, maybe just storing the image in `~/.local/share/...` would make things
simpler than traversing git worktrees. We only need one per system, after all.
Also, we might as well just use the user-specific DNF cachedir in
`/var/tmp/dnf*`.
I'll fix this. Converting to draft in the meantime.
--
... except that would leave all kinds of data around the filesystem, which is
not nice. We want to keep all test-related data contained within the RPM
checkout if possible. Also, we'd have to come up with some kind directory name
to put under `~/.local/share/` (`containers` is already taken by
What's common between the previous SemaphoreCI setup and the current GH Actions
one is that we 1) run in an Ubuntu VM (18.04 -> 22.04) and 2) we run in a
Docker container. My guess would be the latter (Docker) causing this but we yet
have to figure it out :smile:
--
Reply to this email
Then there's the intermittent failure with bwrap's mounting table parsing that
we discussed in the chat. I'm thinking we should have a Known issues sections
somewhere (in the tests/README perhaps) listing these. I'll probably add that
later.
--
Reply to this email directly or view it on
Merged #2589 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2589#event-9949198936
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Since commit 2bdd7d7cbd77b13abf512bb919abe7f0537a2c45, we no longer test the
`systemd-sysusers(8)` implementation shipped by systemd. This also minimizes
the test tree quite a bit since we no longer have to pull in the whole of
systemd.
However, in the CI, we might, just to have that use case
You can view, comment on, or merge this pull request online at:
https://github.com/rpm-software-management/rpm/pull/2591
-- Commit Summary --
* Disable systemd-inhibit in mktree.fedora
* Minimize the package set in mktree.fedora
-- File Changes --
M tests/mktree.fedora (14)
--
Merged #2591 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2591#event-9963362591
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Dont make any assumptions about how other Linux distros would need to
implement the mktree interface. We simply dont know how much logic could
be shared between such native backends before some are actually written.
Right now, we only have one such backend, for Fedora, thats a sample size
too
@dmnks commented on this pull request.
> +return rc;
+}
+
+static int lookup_num(const char *path, const char *val, int vcol, int rcol,
+ long *ret)
+{
+char *buf = NULL;
+int rc = lookup_field(path, val, vcol, rcol, );
+if (rc == 0) {
+ rc =
@dmnks commented on this pull request.
> @@ -132,6 +132,10 @@
%_keyringpath %{_dbpath}/pubkeys/
+# Location of passwd(d) and group(5)
Typo here! Should be `passwd(5)` :smile:
--
Reply to this email directly or view it on GitHub:
> What if we instead had a FA_REFLINK file action (supported in rpm core), and
> the plugin would 1) set this for applicable files 2) supply the necessary
> details such as what to actually reflink to?
I like this idea. In the context of `rpmFileAction`, reflinking indeed can be
seen as a file
@dmnks commented on this pull request.
> @@ -1454,9 +1454,9 @@ RPMDB_INIT
runroot rpmbuild -bb --quiet --define "pkg user" --define "provs %{add_sysuser
u myuser 876 - /home/myuser /bin/sh}"\
/data/SPECS/deptest.spec
-runroot rpm -U /build/RPMS/noarch/deptest-user-1.0-1.noarch.rpm 2>
@dmnks commented on this pull request.
> @@ -1454,9 +1454,9 @@ RPMDB_INIT
runroot rpmbuild -bb --quiet --define "pkg user" --define "provs %{add_sysuser
u myuser 876 - /home/myuser /bin/sh}"\
/data/SPECS/deptest.spec
-runroot rpm -U /build/RPMS/noarch/deptest-user-1.0-1.noarch.rpm 2>
@dmnks commented on this pull request.
> @@ -1454,9 +1454,9 @@ RPMDB_INIT
runroot rpmbuild -bb --quiet --define "pkg user" --define "provs %{add_sysuser
u myuser 876 - /home/myuser /bin/sh}"\
/data/SPECS/deptest.spec
-runroot rpm -U /build/RPMS/noarch/deptest-user-1.0-1.noarch.rpm 2>
@dmnks commented on this pull request.
> @@ -1454,9 +1454,9 @@ RPMDB_INIT
runroot rpmbuild -bb --quiet --define "pkg user" --define "provs %{add_sysuser
u myuser 876 - /home/myuser /bin/sh}"\
/data/SPECS/deptest.spec
-runroot rpm -U /build/RPMS/noarch/deptest-user-1.0-1.noarch.rpm 2>
Apart from the inline comments I made, the change itself looks good!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2503#issuecomment-1604564230
You are receiving this because you are subscribed to this thread.
Message ID:
Merged #2510 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2510#event-9271108448
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
There's currently no guarantee that "RPM build warnings:" and the actual
warnings are printed in the right order, an example here:
https://kojipkgs.fedoraproject.org//work/tasks/2924/101252924/build.log
--
Reply to this email directly or view it on GitHub:
Replace 32-bit sizes in types like off_t with 64-bits when building on 32-bit
architectures, to enable large file support there.
This fixes a nasty regression introduced in the cmake transition. As autotools
would set this flag to 64 automatically for us, applications linking against
librpm
This is caused by the [x86-64 architecture levels
patch](https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847)
shipped in 4.19.0. When determining the target architecture internally in
`rpmPlatform()`, we use `uname(2)` to obtain the system
Yup, having discussed this with the rest of the team, we have to look at fixing
this in RPM after all. It definitely is a regression introduced in 4.19 as
`setarch` had always worked before. I'm putting it in our queue now.
--
Reply to this email directly or view it on GitHub:
Split the Perl dependency generators into a separate GitHub repository managed
by our organization. This will make it far easier for the community to maintain
and is in the spirit of
https://github.com/rpm-software-management/rpm/pull/1607, and more generally,
of
OK, let's do the splitting part ourselves first, via
https://github.com/rpm-software-management/rpm/issues/2873. This PR should then
be migrated to the new repo once it exists. I'll close it here and add a note
to the splitting ticket.
--
Reply to this email directly or view it on GitHub:
Thanks for the patch. We've decided to finally go ahead and split these scripts
into their own repo, though, so I'm closing this one and adding a note to
https://github.com/rpm-software-management/rpm/pull/2609 which tracks the
splitting.
--
Reply to this email directly or view it on GitHub:
Closed #2586.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2586#event-11584153608
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Closed #2609.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2609#event-11584180219
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
> Note that there's no technical reason for _not_ adding the second argument
> (the number of triggering packages) to transaction scriplets here, too. It's
> the same code path underneath.
OK, looking closer, the challenge with transactional file triggers and package
counts is that we can't
When you build locally, do you see the same failure also *without* the patch
associated with the PR in that CI job?
This test has hardcoded checksums to test build reproducibility (with
`SOURCE_DATE_EPOCH` clamping) so whenever the RPM version changes in
`configure.ac` (or `CMakeLists.txt` in
One thing I noticed is that, in this case, even the payload checksums have
changed. An RPM version bump would only affect the header checksums... So there
must be something else at play here.
--
Reply to this email directly or view it on GitHub:
Just FTR, I tried this myself in a Fedora 38 and Fedora 39 container, and it
worked. Or rather, the `--target i386` override on Fedora 39 resulted in the
same outcome as when using `setarch i386` on Fedora 38, which is that rpmbuild
attempted to do a 32bit build. That however failed for me (in
@dmnks commented on this pull request.
> @@ -2451,6 +2453,105 @@ has_bcond(normally_on)
[])
RPMTEST_CLEANUP
+
+
+AT_SETUP([bcond_override_default macros])
+AT_KEYWORDS([bcond build])
+RPMDB_INIT
+
+# check bcond_override_default by defining
+AT_CHECK([
AT_CHECK is deprecated in favor of
OK, I've picked the memleak fixes from #2879, namely 26a132302, 04b3317e6,
7bf818c83 and 5f5fa8852. The first one (f83640306) isn't applicable to the
4.19.x branch since the offending commit isn't there.
--
Reply to this email directly or view it on GitHub:
> This is one where feedback from active packagers would be useful.
Good point! I've brought it to the related discussion
[thread](https://github.com/rpm-software-management/rpm/discussions/2754),
let's see if we get some feedback.
--
Reply to this email directly or view it on GitHub:
With the first argument to file triggers now implemented on master, I wonder
what the semantics of the second argument, if any, should be.
I've submitted a PR (#2883) adding `arg2` that has the same semantics as the
regular triggers, i.e. the number of instances of the *triggering* package to
This sounds a lot like distributing software written in byte-compiled languages
such as Python, which is already covered by the `noarch` target and a set of
RPM macros to aid the packaging process. Typically, the `.pyc` files are
shipped alongside the source code itself in the same binary
OK, having discussed this with the team, let's reopen #2355 and see what we can
do on that front. This issue certainly is something that comes up regularly so
we might as well bite the bullet now.
--
Reply to this email directly or view it on GitHub:
Reopened #2355.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#event-11800812040
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing
As per discussion in #2905, reopening now.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2355#issuecomment-1943636423
You are receiving this because you are subscribed to this thread.
Message ID:
Oh, sure! This looks useful. Please go ahead and submit a PR, we'll take it
from there. Thanks!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2855#issuecomment-1943638444
You are receiving this because you are subscribed to this
@dmnks pushed 3 commits.
eb16077ce74cad62c6017aedc7bbae14c154fd5c Replace MKTREE_NATIVE with
MKTREE_MODE in cmake
b2a80b40b15e30405c7d109109971b392972214e Hybrid mode
38f1e0927b27f5a082f60927c1d85b1dc93d8999 Dockerfile
--
View it on GitHub:
I've just tried this with the latest RPM snapshot on master and this checksum
test still fails, even with commit a0553eb38a01772254cd48fef7ad116294cf801a in
place. This time, though, the payload is identical (as confirmed with
`rpm2cpio` and `diff`). Strange...
--
Reply to this email directly
In any case, #2883 is now merged. We can always tweak this later, at least
before the first public release carrying this feature.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2754#discussioncomment-8452948
You are receiving
> Well, I'm no expert either but my understanding is that for instance a tool
> like `mv` would first try `rename()` and if it returns `EXDEV` it will
> workaround by copying data.
That's correct, I posted a separate comment below covering this part.
> So, to me the main difference is the
Nah, I *was* running it on Ubuntu (by setting up a container manually) :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2874#issuecomment-1941652244
You are receiving this because you are subscribed to this thread.
Message ID:
OK, I was a bit vague above, so to clarify:
What I did was:
1. Ran an Ubuntu-based container (with `toolbox`)
2. Installed all the RPM deps in it
3. Built the latest RPM checkout in it
4. Created an image from it (with `podman commit`)
5. Ran the test-suite against *that* image (instead of the
Looking at the OverlayFS
[docs](https://docs.kernel.org/filesystems/overlayfs.html#renaming-directories)
some more, specifically at the section covering `redirect_dir`, it mentions the
following (emphasis mine):
> return EXDEV error: this error is returned by rename(2) when trying to move a
>
Right, that is a valid question, although I'm no expert on OverlayFS so can't
really answer that.
The only "explanation" (as to why EXDEV is issued on a `rename(2)` call) that
I've found is the following excerpt from a comment in the OverlayFS
Yup, this is a known issue, see
https://github.com/rpm-software-management/rpm/issues/2355.
The thing is, even if this would be possible to work around, we don't want to
have any such filesystem-specific code in RPM.
Now, thinking about it more, this might in fact be something to handle in an
> Well, I'm no expert either but my understanding is that for instance a tool
> like `mv` would first try `rename()` and if it returns `EXDEV` it will
> workaround by copying data.
That's correct, I posted a separate comment below covering this part.
> So, to me the main difference is the
Hmm, it seems like OverlayFS indeed does a full copy up (there's the `metacopy`
feature that only does that for the metadata).
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2905#discussioncomment-8456485
You are receiving this
This is already fixed in the rpm-l10n repo, in the commit
https://github.com/rpm-software-management/rpm-l10n/commit/b4dc72f4b92489f77de9b0ae0bed754875d37ece,
we just need to update the `po` submodule in the main repo to pull that change.
> IMO It would be hoof to add excutinh that target at
Oh, and just to clarify, in the case of 4.19.1.1, we did *not* intend to update
the translations in that release at all, which is why this issue wasn't caught
yet.
--
Reply to this email directly or view it on GitHub:
Merged #2906 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2906#event-11874927721
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Closed #2890 as completed via #2906.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2890#event-11874927944
You are receiving this because you are subscribed to this thread.
Message ID:
___
To summarize my above comments a bit, from a higher-level perspective:
In the context of the shared `%_topdir`, an RPM package doesn't necessarily
have to correspond to a single program or piece of software. It's a way to
distribute a "snapshot" or "sub-tree" of the root filesystem. In that
Thinking more about it, the shared BUILDROOT use case might actually be
impossible to achieve because of the fact that RPM checks for unpackaged files
in there when building a single package (see the recent discussions around
excludes).
--
Reply to this email directly or view it on GitHub:
One thing to keep in mind here is that we'll be getting rid of a shared
BUILDROOT. I've always wondered what the purpose of that (or the shared
`%_topdir` workspace in general) was, but I can think of one use case:
You wish to deploy a common set of packages and/or configuration (a *suite*) to
Which makes me think - couldn't the shared BUILDROOT be useful for actually
building container images? I'm not sure about the advantages over just grabbing
pre-built RPMs to compose the final root filesystem tree, but it does seem like
you'd save a number of redundant steps if you were building
I agree with @ppisar and @pmatilai above, this proposal seems to be sitting one
"floor" above us. We don't deal with repositories or the distribution of
packages in general.
That said, of course, if anything comes out of this discussion that impacts RPM
itself, we're happy to help. Also, like
The absence of the `%build` script shouldn't have any effect on whether the
stripping occurs or not. In fact, the `brp-strip` script is called *after* the
`%install` script.
I'd suspect there to be some other reason the binaries aren't stripped for you.
Can you share the `rpmbuild` output?
--
This is a bug fix only release addressing a number of regressions, memory leaks
and build system issues, namely:
* *Packaging:* Don't warn about missing user/group on skipped files
Regression
([#2814](https://github.com/rpm-software-management/rpm/pull/2814))
* *Packaging:* Make user/group
Closed #2878 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2878#event-11734044206
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
This is a bug fix only release addressing a number of regressions, memory leaks
and build system issues, namely:
* Packaging: Don't warn about missing user/group on [...] [Regression] (#2814)
* Packaging: Make user/group lookup caching thread-safe [Regression] (#2843)
* Lua interface: Fix
Not a fan of the `-root` suffix. Now that we have the option, why not take full
advantage of directories and have a tree like this:
```
BUILD/
├── bar-1.0
│ ├── ROOT
│ │ └── x86_64-linux
│ │ └── [...]
│ └── SPECPARTS
└── foo-1.0
├── ROOT
│ └── x86_64-linux
│ └── [...]
@dmnks commented on this pull request.
> @@ -303,6 +300,24 @@ static rpmRC doCheckBuildRequires(rpmts ts, rpmSpec
> spec, int test)
return rc;
}
+static rpmRC doBuildDir(rpmSpec spec, int test, StringBuf *sbp)
+{
+char *doDir = rstrscat(NULL,
+ "rm -rf ",
Merged #2888 into rpm-4.19.x.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2888#event-11732556078
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Changelog updated.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/discussions/2810#discussioncomment-7854267
You are receiving this because you are subscribed to this thread.
Message ID:
___
@dmnks pushed 11 commits.
d4ea40e1899867781b3038b86dad39777d08 Silence not-documented warnings from
Doxygen
269075562b42e8f127ad56afe594ef90ee6618a4 Honor ENABLE_WERROR on Doxygen too
9291d900fc862d8cfbb1dd884b1d882854ba8ab7 Optimize Doxygen output for C
Merged #2791 into rpm-4.19.x.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2791#event-11221883573
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Excerpt from `git range-diff` showing the added commits:
```
-: - > 243: 79cca0a9e Split the two rpm2archive tests to separate
test-cases
-: - > 244: 2de414acd Use the expected rpm2cpio-like syntax for
rpm2archive tests
-: - > 245: 156fd9cc3 Fix some invalid
@dmnks pushed 35 commits.
79cca0a9e9e80f5029ded3469cd3889c96cd675a Split the two rpm2archive tests to
separate test-cases
2de414acd2c111a3526b640170772e4731805970 Use the expected rpm2cpio-like syntax
for rpm2archive tests
156fd9cc3d9385eef99ac6b4e89c782bef6d4397 Fix some invalid rpm2cpio
A note on the changelog: The categories are a bit arbitrary at this moment as
this is the first release with an automatically generated changelog. We're
going to tweak it a bit more and update it here later.
--
Reply to this email directly or view it on GitHub:
This file (added in commit e0dd875175cf08a1bc11b8ac63badd5d8ff08a93) actually
shouldn't be installed on `make install`. It ends up alongside the `README`
file from this repo's top-level directory, in `%{_defaultdocdir}` which is just
confusing and unnecessary.
--
Reply to this email directly
This is the first update to the 4.19 series, mostly addressing bugs and
regressions, with a few small improvements added on top. The changelog
follows:
Regression fixes
* Never use current user info or file ownership during build (#2797)
Command line
* Print full path if file removal
This is the first update to the 4.19 series, mostly addressing bugs and
regressions, with a few small improvements added on top. The changelog follows:
Regression fixes
* Never use current user info or file ownership during build
I also updated the README to make it a bit more clear.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1850090417
You are receiving this because you are subscribed to this thread.
Message ID:
"version-diff" indeed is perhaps closer to what it does, however it just
happens that these tests depend on the version. There might as well be other
tests (in the future) that depend on some other baked-in value.
"release-prep" is similarly too generic because this really is just about the
The idea behind this kind of tests is basically this: We need to *track* the
expected output in the repository so that we ensure it's always the same when
running the given test, which is why don't just dynamically determine the
expected output at test-runtime. At the same time, we need this
OK, in the end I went with simply `pinned`. When I was updating the commit, it
became apparent "mutable" just didn't fit well in the context, and also clashed
with the other meaning I'd mentioned...
--
Reply to this email directly or view it on GitHub:
@dmnks pushed 1 commit.
42b6792c91dd951e21ab37485955fa68195009cd Add support for "pinned" tests
--
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803/files/2973e1957638cae6807783ee6f50e13b248164f9..42b6792c91dd951e21ab37485955fa68195009cd
You are receiving this because
Yup, annoyingly as well as amusingly long :smile: But as a rule of thumb,
naming make targets after the "artifacts" they produce rather than the "action"
they do is always better, at least IMO (of course we don't follow that
precisely but that's fine).
--
Reply to this email directly or view
Merged #2806 into master.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2806#event-11211977757
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
... which makes me think about another target name: update-tests :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1849710161
You are receiving this because you are subscribed to this thread.
Message ID:
And perhaps, if we were to put all the test-related targets behind the "check-"
prefix, then "check-update"...
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2803#issuecomment-1849711377
You are receiving this because you are subscribed
Oh! That's a pretty good idea! :smile:
... except that "mutable" is already used in the test context. But - that
doesn't matter much, I suppose. It's a lower-level detail that's relevant when
*writing* a test. Otherwise, "mutable" is indeed the best fit.
So, let's just go with that.
--
> We should support all the same features for a file list entry here, which
> also means being able to handle regular expressions.
We don't support regexes in a `%files` entry, though, only globs.
--
Reply to this email directly or view it on GitHub:
> * Non-trans scriptlets have should get a second argument reflecting the
> triggering package count
I wonder if we want the triggering package count (`arg2`) to be an *aggregate*
count of all the triggering packages or just that of the *first* match?
There's a subtle difference in the
Good point! We shouldn't just blindly copy what the normal triggers do here.
There's enough difference that it makes sense to step back for a moment and
think about what functionality and use cases we really want to cover. Thanks,
I'll take that into account :smile:
--
Reply to this email
Thanks, the part about usefulness is actually on point :smile: That said, I
haven't given it too much thought either, this is just the most obvious
solution that comes to mind. I'll ponder about it a bit more but there's
probably not much to ponder about anyway.
--
Reply to this email
Yup, we recently refactored quite a bit of code related to glob handling, and
mostly went with the GNU `glob(3)` implementation, meaning that at least
`GLOB_BRACE` is indeed used now. Previously, we had our own implementation of
brace expansion, IIRC.
I'll have a closer look but it's possible
701 - 800 of 1032 matches
Mail list logo
