`rpm -i` **=** _installation invocation_ which implies availability.
`rpm -i` **!=** _installed query_ thus **!=** `rpm -q`.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/3132#issuecomment-2143430123
You are receiving this because you
### Describe the bug
Existing package not found
### To reproduce
```
$ sudo rpm -vv -i rubygem-bundler
D: == rubygem-bundler
error: open of rubygem-bundler failed: No such file or directory
D: found 0 source and 0 binary packages
D: Exit status: 1
```
### Expected behaviour
Proceed to i
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 favor
**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
SDL2-0:2.26.3-1.
```
$ 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 f
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 Fed
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} libxcrypt-co
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 ma
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: __
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 : Public
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 of
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 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.
`URL0=https://nic.funet.fi/pub/Linux/INSTALL/fedora/linux/rele
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
fo
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
fo
```
$ 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 libv
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 since
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
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_ va
"_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 --qf
"_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 --qf
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: ___
Rpm
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 adequate
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:
https://github.c
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:
htt
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 description,
28 matches
Mail list logo