Merged #1755 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/1755#event-5292933503___
Rpm-maint mailing list
Rpm-mai
@pmatilai approved this pull request.
Fine with me :+1:
--
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/1755#pullrequestreview-752743955_
@dmnks pushed 2 commits.
ee00def1680016b5bbaaf86693b6b1408f4ea04e Add test for file query
0d2ede6c585b01398b64993907dffcdd3f4ff19b Add support for RPMDBI_BASENAMES on
file queries
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-s
@dmnks pushed 1 commit.
07c6ef65cb4a19f45a72e73cff0beb8f776c989e Add support for RPMDBI_BASENAMES on
file queries
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1755/files/a95afc43831336a8dfcf8ade6861
> Oh, indeed. There are a few additional subtleties there as you point out, and
> my "whether on disk or not" is not quite right. I think I originally wrote
> that "whether installed or not", which is closer to the point, but then I
> changed to "on disk" because "installed" may refer to package
Oh, indeed. There are a few additional subtleties there as you point out, and
my "whether on disk or not" is not quite right. I think I originally wrote that
"whether installed or not", which is closer to the point, but then I changed to
"on disk" because "installed" may refer to package or a fi
> At least to me, "file" seems to refer to something concrete, eg on-disk file,
> whereas a "path" is more abstract so it matches the case quite nicely.
Yep, that's exactly what I was going for :wink: I'm glad it clicked for you too!
> I'd simplify the documentation though: update `--file` to sa
At least to me, "file" seems to refer to something concrete, eg on-disk file,
whereas a "path" is more abstract so it matches the case quite nicely. I'd
simplify the documentation though: update `--file` to say: "Query package(s)
owning installed *FILE*" (which I should've done when changing the
I've pushed a more straightforward version that adds `--path` as an alternative
to `--file` that considers all files in the rpmdb, whether or not they're in
fact installed on disk. Let me know your thoughts.
--
You are receiving this because you are subscribed to this thread.
Reply to this emai
@dmnks pushed 1 commit.
7762dfb325362708ba51437be6802839dd255e73 Add support for RPMDBI_BASENAMES on
file queries
--
You are receiving this because you are subscribed to this thread.
View it on GitHub:
https://github.com/rpm-software-management/rpm/pull/1755/files/0a02f213fe3ca92e016c5ef67ad7
Eh, you're right. It turns out the handling of `--allfiles` is consumed
entirely by the callback that my patch is adding, making the original
install-time option ineffective. Thanks for noticing...
This is because, in the `rpmInstallPoptTable`, the existing option is using
`POPT_BIT_SET` and th
> This being rpm though... does this end up overriding the install-side
> --allfiles flag behavior?
Answering myself, yes it does. Without this patch:
```
[root@localhost rpm]# ./rpm -e --allfiles telnet
lt-rpm: --allfiles may only be specified during package installation
[root@localhost rpm]#
``
The patch is straightforward enough as such. This being rpm though... does
this end up overriding the install-side --allfiles flag behavior? I seem to
recall ambiguous flags in popt needing to be handled through a callback instead
because of that, but it's been a while.
I'm also pondering abou
* Add the `--allfiles` switch which augments `-qf`
* Add a basic test for `-qf` while at it
* Update the list of possible file states in the man page (needed for
consistency with the new `--allfiles` description)
You can view, comment on, or merge this pull request online at:
https://github.com
14 matches
Mail list logo
