Command option '_--qf_' applies **only** to **parameter attached** to option
'-_q_' (here _rpm_), not to each output row as expected. (Possible bug)
Actual result:
```
$ rpm -qR rpm --qf '%{NAME} – %{DESCRIPTION}'
/usr/bin/bash
(...)
rpm – The RPM Package Manager (RPM) (...)
(...) a
Indeed. I had figured out the supported fields list using ’rpm --querytags’.
Yet I fail to discover a way to print each tag description; Do you have a
suggestion for that?
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
Issue valid with tag _nevra_.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2364#issuecomment-1402245979
You are receiving this because you are subscribed to this thread.
Message ID: ___
Hello. [Here](https://rpm.org/documentation.html), the page referred in the
link for _Fedora RPM Guide_ is
[reported](https://docs.fedoraproject.org/en-US/Fedora_Draft_Documentation/0.1/html/RPM_Guide/index.html)
not found.
--
Reply to this email directly or view it on GitHub:
Hello. Tag _evr_ fails to query the values intended to be queried by tag
_epoch_.
```
$ rpm -q --qf %{evr} rpm
4.18.0-1.fc37
```
Though the underlying function for tag _epoch_ behaves as intended.
```
$ rpm -q --qf %{epoch} rpm
(none)
```
Though _0_ instead of _(none)_ could be a bit more
"_That package does not HAVE an epoch_"
Wasn't it explicit from my output resulting `rpm -q --qf %{epoch} rpm`?
"_That package does not HAVE an epoch, so it's not reported._"
Well, not reported! Was there something that prevented you from reading a
_(none)_ from my output resulting `rpm -q
"_That package does not HAVE an epoch_"
Wasn't it explicit from my output resulting `rpm -q --qf %{epoch} rpm`?
"_That package does not HAVE an epoch, so it's not reported._"
Well, not reported! Was there something that prevented you from reading a
_(none)_ from my output resulting `rpm -q
There cannot be better model for illustrating a bad use of convention, since
such a convention could not be determined invariably as a convention.
**Proof-case**
Is assumed:
- a **non-null** _epoch_ value exits for an installed package
- user not aware of the exitence of a **non-null** _epoch_
There cannot be better model for illustrating a bad use of convention, since
such a convention could not be determined invariably as a convention.
**Proof-case**
Is assumed:
- a **non-null** _epoch_ value exits for an installed package
- user not aware of the existence of a **non-null** _epoch_
**v.** 4.18.1 | Hello. `rpm` fails to report the package that requires the
specified package, while the existence of the package it is required by is
attested by `dnf` .
```
$ rpm -q --whatrequires libdecor
no package requires libdecor
$ dnf rq --installed --whatrequires libdecor
```
$ rpm -e --test libdecor
error: Failed dependencies:
(libdecor-0.so.0()(64bit) if libwayland-client) is needed by
(installed) SDL2-2.26.3-1.fc38.x86_64
```
**v. 4.18.1** | Hello. The above output's formulation makes it highly uneasy to
interpret correctly, so i had to investigate to
correction | additions of headers representing tags are possible.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2411#issuecomment-1470183107
You are receiving this because you are subscribed to this thread.
Message ID:
Along with that unconventional issue, the user is probably left with an
unknown: _How to determine how or by who the Red Hat GPG/DSA key was imported?_
Could it be me that imported a such package?
```
$ rpm -qa --scripts gpg-pubkey* --qf '%{version}-%{release} %{packager}\n'
5323552a-6112bcdc
Fake package can be identifiable by the prefix _gpg-pubkey-_ in its name;
that's a knowledge assumed unknown from the user nor was assumed needed the
knowledge of the definition of a fake package. Yet it is unusual for the vast
majority of users (be they beginners or even advanced) to be put in
Fake package can be identifiable by the prefix _gpg-pubkey-_ in its name;
that's a knowledge assumed unknown from the user nor was assumed needed the
knowledge of the definition of a fake package. The **title** could not be more
explicit in this regard. Yet it is unusual for the vast majority
Certainly; thus no issue in the traditional sense.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2410#issuecomment-1454761223
You are receiving this because you are subscribed to this thread.
Message ID:
Closed #2410 as completed.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/2410#event-8666192273
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint
Hello. A **non-manually** created fake RPM package is reported as follows
```
$ rpm -qi gpg-pubkey-5323552a-6112bcdc | awk 'NF' | sed -n '1,17p;$p'
Name: gpg-pubkey
Version : 5323552a
Release : 6112bcdc
Architecture: (none)
Install Date: Sat Nov 5 11:14:03 2022
Group :
Package specified reported in output
Hello. Noticeable issues:
- Queried **tag fields are not exhibited** along with each reported package
name.
- The **specified package name is reported**. Nonetheless in that context,
queried tag fields are exhibited.
```
$ rpm -q --qf %{version}
Hello. Fake RPM packages with GPG keys associated with them are taken in
account while querying all installed packages.
```
$ rpm -qa | grep '^gpg-pubkey-' | wc -l
2
```
This ability to count such packages, which is useful, would be more to its
advantage if queried on-demand and thus served by a
```
$ rpm -q rpm
rpm-4.18.0-1.fc37.x86_64
```
Attestation of availability of a package: with `dnf`
```
$ dnf -q rq --repo=fedora libvirt-client
libvirt-client-0:8.6.0-3.fc37.x86_64
```
Hello. Opening of package failing.
```
$ rpm -vv -qip `dnf -q rq --repo=fedora libvirt-client`
error: open of
How i could miss the presence of that option? Then unlike what i wrote,
"_Option missing from RPM(8), 09 June 2002_", it was present. It would be worth
to have an explicit description such as one that takes in account your
statement "_rpm -qp queries a local .rpm file_". Would the following
How i could miss the presence of that option? Then unlike what i wrote,
"_Option missing from RPM(8), 09 June 2002_", it was present. It would be worth
to have an explicit description such as one that takes in account your
statement "_rpm -qp queries a local .rpm file_". Would the following
**rpm v.**: 4.18.0-1.fc37.x86_64
Hello. Steps to reproduce; to be applied to a **non-installed** package, here
`libvirt-client` for instance.
Ensure that a correct value for`--repo` is set according to the OS you are
working with.
So that is all what it was about; **deliberate inconsistency.** Choosing to
print sometimes _epoch_ values, with tag _epoch_, and sometimes not to print
them, with tags _evr_ and _nevra_, would not be expected from developers.
Having such a fantasy in your code must have pleased you so far
Hello. In light of the fiasco caused by the discovery of a backdoor in the
component _xz_ in a known version range, is there at this time a consensus on
compression for future releases within the RPM/DNF component developer teams,
in order to consider moving away from **XZ Utils**, e.g. in
26 matches
Mail list logo
